Solved: After Upgrade from freeradius 2 to 3 (Debian 8 - 9): TLS Alert write:fatal:unsupported certificate
I would like to summarize the topic for FreeRadius. The error discussed is actually due to a change in OpenSSL1.1. My request in the OpenSSL user group on this topic has led to a controversial discussion. Of course the certificates are RFC compliant. Unfortunately, OpenSSL does not evaluate the ExtendedKeyUsage (eku) as defined in the RFC in question. In the case discussed here, ExtednedKeyUsage (eku) is set to TLS "Web Server Authentication" for the CA (CAPF) certificate. This would be allowable under RFC, but is not allowed by the openssl client certificate validation functions. The background: An eku is evaluated in a CA so that only these defined extensions can be used, if it is defined. If no EKU is defined, there are no restrictions. This means I would need to add either "TLS WEB Client Authentification" or delete "TLS WEB Server Authentification". The solution for us was, that we changed the csr and removed the ExtendedKeyUsage "TLS Web Server Authentification". So the Cisco CUCM got the CAPF with the eku and the radius of one without any eku. Unfortunately, this is not a solution for customers who use the certificate signed by Cisco CallManagers themselves, as the eku for the freeradius can not simply be deleted here. This means, that there is no chance to authenticate the phones with a freeradius version based on openssl libraries> = 1.1.0 - at least not with tls. Remedy would only create a correctly patched openssl version or the correct implementation of an openssl_verify function (as discussed in openssl thread). But as Alan had said defiantly, then the affected but the Cisco ACS / ISE take. Robert -----Ursprüngliche Nachricht----- Von: Gladewitz, Robert Gesendet: Freitag, 19. Januar 2018 11:40 An: Gladewitz, Robert <Robert.Gladewitz@dbfz.de>; FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Betreff: AW: After Upgrade from freeradius 2 to 3 (Debian 8 - 9): TLS Alert write:fatal:unsupported certificate I forget a higher debuglevel. What mean: in __FUNCTION__ (SSL_read): ../ssl/statem/statem_srvr.c[2896]:error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed ??? <SNIP> Fri Jan 19 11:35:32 2018 : Debug: (3) eap_tls: Continuing EAP-TLS Fri Jan 19 11:35:32 2018 : Debug: (3) eap_tls: Peer sent flags --L Fri Jan 19 11:35:32 2018 : Debug: (3) eap_tls: Peer indicated complete TLS record size will be 1432 bytes Fri Jan 19 11:35:32 2018 : Debug: (3) eap_tls: Got complete TLS record (1432 bytes) Fri Jan 19 11:35:32 2018 : Debug: (3) eap_tls: [eaptls verify] = length included Fri Jan 19 11:35:32 2018 : Debug: Ignoring cbtls_msg call with pseudo content type 256, version 0 Fri Jan 19 11:35:32 2018 : Debug: (3) eap_tls: TLS_accept: SSLv3/TLS write server done Fri Jan 19 11:35:32 2018 : Debug: (3) eap_tls: <<< recv TLS 1.0 Handshake [length 03c2], Certificate Fri Jan 19 11:35:32 2018 : Debug: (3) eap_tls: Creating attributes from certificate OIDs Fri Jan 19 11:35:32 2018 : Debug: (3) eap_tls: TLS-Cert-Serial := "1009" Fri Jan 19 11:35:32 2018 : Debug: (3) eap_tls: TLS-Cert-Expiration := "380111125719Z" Fri Jan 19 11:35:32 2018 : Debug: (3) eap_tls: TLS-Cert-Subject := "/C=DE/ST=Sachsen/L=Leipzig/O=DBFZ Deutsches Biomasseforschungszentrum gGmbH/OU=IT/CN=CAPF-91d43ef6" Fri Jan 19 11:35:32 2018 : Debug: (3) 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@dbfz.de" Fri Jan 19 11:35:32 2018 : Debug: (3) eap_tls: TLS-Cert-Common-Name := "CAPF-91d43ef6" Fri Jan 19 11:35:32 2018 : ERROR: (3) eap_tls: SSL says error 26 : unsupported certificate purpose Fri Jan 19 11:35:32 2018 : Debug: Ignoring cbtls_msg call with pseudo content type 256, version 0 Fri Jan 19 11:35:32 2018 : Debug: (3) eap_tls: >>> send TLS 1.0 Alert [length 0002], fatal unsupported_certificate Fri Jan 19 11:35:32 2018 : ERROR: (3) eap_tls: TLS Alert write:fatal:unsupported certificate Fri Jan 19 11:35:32 2018 : Error: tls: TLS_accept: Error in error Fri Jan 19 11:35:32 2018 : ERROR: (3) eap_tls: Failed in __FUNCTION__ (SSL_read): ../ssl/statem/statem_srvr.c[2896]:error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed Fri Jan 19 11:35:32 2018 : ERROR: (3) eap_tls: System call (I/O) error (-1) Fri Jan 19 11:35:32 2018 : ERROR: (3) eap_tls: TLS receive handshake failed during operation Fri Jan 19 11:35:32 2018 : ERROR: (3) eap_tls: [eaptls process] = fail Fri Jan 19 11:35:32 2018 : ERROR: (3) eap8021xciscophone: Failed continuing EAP TLS (13) session. EAP sub-module failed </SNIP> -----Ursprüngliche Nachricht----- Von: Freeradius-Users [mailto:freeradius-users-bounces+robert.gladewitz=dbfz.de@lists.freeradius.org] Im Auftrag von Gladewitz, Robert via Freeradius-Users Gesendet: Freitag, 19. Januar 2018 10:28 An: freeradius-users@lists.freeradius.org Betreff: AW: After Upgrade from freeradius 2 to 3 (Debian 8 - 9): TLS Alert write:fatal:unsupported certificate Hello, in first discusion, the errors seems tob e on a wrong ca certificate. Now, all certifices a changed an the errror still happening: <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@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> openssl -verify have no warning, if I do cert check manually. Fo testing, I append the certs. # openssl verify -verbose -CAfile /etc/freeradius/3.0/certs.8021x.ciscophone/cacert.capf.pem SEP64A0E714844E-L1.pem # SEP64A0E714844E-L1.pem: OK Regards Robert -----Ursprüngliche Nachricht----- Von: Stefan Winter [mailto:stefan.winter@restena.lu] Gesendet: Donnerstag, 21. Dezember 2017 14:52 An: FreeRadius users mailing list <freeradius-users@lists.freeradius.org>; Boris Lytochkin <lytboris@yandex-team.ru>; Gladewitz, Robert <Robert.Gladewitz@dbfz.de> Betreff: Re: After Upgrade from freeradius 2 to 3 (Debian 8 - 9): TLS Alert write:fatal:unsupported certificate Hi,
It's much better to fix your "CA" cert (which is not). ================ X509v3 Basic Constraints: critical CA:TRUE ================ is missing.
Out of curiosity (I didn't think Cisco can be so stupid to make CAs which aren't actually CAs...) I searched, and my search engine of choice gave me this link: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCut82798/?referring_site=bug... (needs free registration to view) So, indeed, Cisco WAS that stupid. For an extended amount of time and multiple major version releases. FWIW, if the OP can upgrade his system to release 11.5 and re-generate the CAPF CA, then he should get a real CA. Which then makes tinkering with source code obsolete. (If the answer is that you need to edit the source code, then you are asking the wrong question :-) ) Greetings, Stefan Winter Am 20.12.2017 um 07:51 schrieb Boris Lytochkin:
Hi.
See http://www.alvestrand.no/objectid/2.5.29.19.html
On 20.12.2017 1:09, Gladewitz, Robert via Freeradius-Users wrote:
Hello Alan,
so, i find out that you are right. I find out, that the certificate check ends with an warning, because of following openssl function in v3_purp.c?
495 /*- 496 * CA checks common to all purposes 497 * return codes: 498 * 0 not a CA 499 * 1 is a CA 500 * 2 basicConstraints absent so "maybe" a CA 501 * 3 basicConstraints absent but self signed V1. 502 * 4 basicConstraints absent but keyUsage present and keyCertSign asserted. 503 */ 504 505 static int check_ca(const X509 *x) 506 { 507 /* keyUsage if present should allow cert signing */ 508 if (ku_reject(x, KU_KEY_CERT_SIGN)) 509 return 0; 510 if (x->ex_flags & EXFLAG_BCONS) { 511 if (x->ex_flags & EXFLAG_CA) 512 return 1; 513 /* If basicConstraints says not a CA then say so */ 514 else 515 return 0; 516 } else { 517 /* we support V1 roots for... uh, I don't really know why. */ 518 if ((x->ex_flags & V1_ROOT) == V1_ROOT) 519 return 3; 520 /* 521 * If key usage present it must have certSign so tolerate it 522 */ 523 else if (x->ex_flags & EXFLAG_KUSAGE) 524 return 4; 525 /* Older certificates could have Netscape-specific CA types */ 526 else if (x->ex_flags & EXFLAG_NSCERT && x->ex_nscert & NS_ANY_CA) 527 return 5; 528 /* can this still be regarded a CA certificate? I doubt it */ 529 return 0; 530 } 531 }
But it is documented as a warning, not an error!?
It is possible, to add an workarround for mistake in conf / tls.c
<DIFF tls.c> if (!my_ok && (conf->allow_expired_crl) && (err == X509_V_ERR_CRL_HAS_EXPIRED)) { my_ok = 1; X509_STORE_CTX_set_error( ctx, 0 ); }
+ if (!my_ok && + (conf->allow_wrong_purposed) && + (err == X509_V_ERR_INVALID_PURPOSE)) { + my_ok = 1; + X509_STORE_CTX_set_error( ctx, 0 ); + }
if (!my_ok) {
</DIFF>
I hope, my mail not sounds arogant :-(
Robert
-----Ursprüngliche Nachricht----- Von: Freeradius-Users [mailto:freeradius-users-bounces+robert.gladewitz=dbfz.de@lists.freer adius.org] Im Auftrag von Alan DeKok Gesendet: Dienstag, 19. Dezember 2017 18:49 An: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Betreff: Re: After Upgrade from freeradius 2 to 3 (Debian 8 - 9): TLS Alert write:fatal:unsupported certificate
On Dec 19, 2017, at 12:18 PM, Boris Lytochkin <lytboris@yandex-team.ru> wrote: Alan, you are absolutely correct about OIDs. But one thing drives me crazy. Robert sent me a full capture (attached) and it is really weird if you compare it to FreeRADIUS logs. ... I have no idea why FreeRADIUS peeks issuer's cert instead of real client's one. I guess something is broken in server's configuration... EAP-TLS sends over the entire certificate chain. OpenSSL walks down the certificate chain, verifying each cert in sequence.
If it can't verify the CA or server cert, OpenSSL fails, and we never get to check the client cert.
When the client cert gets printed, the fields get printed as "TLS-Client-Cert-Serial", not as "TLS-Cert-Serial"
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 2, avenue de l'Université L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
On Jan 24, 2018, at 2:16 AM, Gladewitz, Robert via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
I would like to summarize the topic for FreeRadius.
The error discussed is actually due to a change in OpenSSL1.1. My request in the OpenSSL user group on this topic has led to a controversial discussion.
Of course the certificates are RFC compliant. Unfortunately, OpenSSL does not evaluate the ExtendedKeyUsage (eku) as defined in the RFC in question.\
The OpenSSL team gave you very clear reasons why on their mailing list. One of which is that the RFCs are probably being updated to match current implementations. As someone who's written many RFCs, they're not perfect. See RFC 5080, for example, which points out errors in earlier RFCs, and describes the correct behaviour. The "correct" behaviour in many cases is "what the implementations have been doing for a decade". There are cases where FreeRADIUS does not follow the RFCs. These are cases where the RFCs are broken or wrong.
In the case discussed here, ExtednedKeyUsage (eku) is set to TLS "Web Server Authentication" for the CA (CAPF) certificate.
This would be allowable under RFC, but is not allowed by the openssl client certificate validation functions.
Or by most implementations, as you were told on the OpenSSL list. And that they believe the RFCs are wrong.
Unfortunately, this is not a solution for customers who use the certificate signed by Cisco CallManagers themselves, as the eku for the freeradius can not simply be deleted here. This means, that there is no chance to authenticate the phones with a freeradius version based on openssl libraries> = 1.1.0 - at least not with tls.
How about complaining to Cisco, and getting their implementation fixed? Oh wait, Stefan already told you how to fix it. You can:
upgrade his system to release 11.5 and re-generate the CAPF CA, then he should get a real CA.
Remedy would only create a correctly patched openssl version or the correct implementation of an openssl_verify function (as discussed in openssl thread).
Stop trolling. It's rude, and will result in you getting kicked off of the list. I've already warned you once off-list. This is your last, and final warning. You're claiming here that the "correct" implementation of OpenSSL is whatever you think it is, and that the OpenSSL developers are wrong. You're making that same claim about FreeRADIUS. You *could* choose to upgrade the Cisco software to a version which is fixed. Instead, you insist on claiming that you know better than everyone else, and that everyone's software is wrong. There is no language problem here. You're choosing to be obnoxious. Stop it. Alan DeKok.
Hello Alen, it seems to me, you have not read the openssl thread completely. The openssl interpretation is not rfc compliant. We have already switched to the latest callmanager version! Originally since you here in the forum assumed that the ku "CA" is missing. This error is actually fixed. Nevertheless, the CAPF CA certificates are still issued with the eku "TLS WEB SERVER Authentification", or predefined in the csr. Cisco apparently also needs this option, for whatever reason. That's why I've documented the whole thing for this forum - because I've also gotten two direct requests with the same problem. I also think that this problem is coming to bear more and more because many customers are only now gradually switching to systems based on openssl1.1.0 or higher. To be honest, I can not understand why you are allowed to criticize yourself a lot, but you do not concede any criticisms or mistakes yourself. Really sad, because freeradius ansich is a very good pruduct. When annotations and suggestions for improvement are always treated in this way, at some point nobody dares to make any suggestions. That's a pity. -----Ursprüngliche Nachricht----- Von: Alan DeKok [mailto:aland@deployingradius.com] Gesendet: Mittwoch, 24. Januar 2018 09:13 An: Gladewitz, Robert <Robert.Gladewitz@dbfz.de>; FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Betreff: Re: Solved: After Upgrade from freeradius 2 to 3 (Debian 8 - 9): TLS Alert write:fatal:unsupported certificate On Jan 24, 2018, at 2:16 AM, Gladewitz, Robert via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
I would like to summarize the topic for FreeRadius.
The error discussed is actually due to a change in OpenSSL1.1. My request
in the OpenSSL user group on this topic has led to a controversial discussion.
Of course the certificates are RFC compliant. Unfortunately, OpenSSL does
not evaluate the ExtendedKeyUsage (eku) as defined in the RFC in question.\ The OpenSSL team gave you very clear reasons why on their mailing list. One of which is that the RFCs are probably being updated to match current implementations. As someone who's written many RFCs, they're not perfect. See RFC 5080, for example, which points out errors in earlier RFCs, and describes the correct behaviour. The "correct" behaviour in many cases is "what the implementations have been doing for a decade". There are cases where FreeRADIUS does not follow the RFCs. These are cases where the RFCs are broken or wrong.
In the case discussed here, ExtednedKeyUsage (eku) is set to TLS "Web Server Authentication" for the CA (CAPF) certificate.
This would be allowable under RFC, but is not allowed by the openssl client certificate validation functions.
Or by most implementations, as you were told on the OpenSSL list. And that they believe the RFCs are wrong.
Unfortunately, this is not a solution for customers who use the certificate signed by Cisco CallManagers themselves, as the eku for the freeradius can not simply be deleted here. This means, that there is no chance to authenticate the phones with a freeradius version based on openssl libraries> = 1.1.0 - at least not with tls.
How about complaining to Cisco, and getting their implementation fixed? Oh wait, Stefan already told you how to fix it. You can:
upgrade his system to release 11.5 and re-generate the CAPF CA, then he should get a real CA.
Remedy would only create a correctly patched openssl version or the correct implementation of an openssl_verify function (as discussed in openssl thread).
Stop trolling. It's rude, and will result in you getting kicked off of the list. I've already warned you once off-list. This is your last, and final warning. You're claiming here that the "correct" implementation of OpenSSL is whatever you think it is, and that the OpenSSL developers are wrong. You're making that same claim about FreeRADIUS. You *could* choose to upgrade the Cisco software to a version which is fixed. Instead, you insist on claiming that you know better than everyone else, and that everyone's software is wrong. There is no language problem here. You're choosing to be obnoxious. Stop it. Alan DeKok.
On Jan 24, 2018, at 5:15 AM, Gladewitz, Robert <Robert.Gladewitz@dbfz.de> wrote:
Hello Alen, it seems to me, you have not read the openssl thread completely.
It seems you're still being rude, specifically:
The openssl interpretation is not rfc compliant.
I know. In the message you responded to (and you quoted), I said this. I explained why it's not RFC compliant. I explained why RFC compliance isn't always necessary. Did you: a) not read the message you're replying to? or b) read it, and not understand it? I'll also note that you showed the same issues on the OpenSSL forum: they explained things, you didn't understand the explanations, and you argued with them. At which point they ignored you.
To be honest, I can not understand why you are allowed to criticize yourself a lot, but you do not concede any criticisms or mistakes yourself.
Clearly. I've explained repeatedly, and you still don't understand. That's a problem I can't fix.
Really sad, because freeradius ansich is a very good pruduct. When annotations and suggestions for improvement are always treated in this way, at some point nobody dares to make any suggestions. That's a pity.
You're now lying about what's going on. I am more than happy to take suggestions for improvement. The last 20 years of the project make that abundantly clear. Anyone who claims otherwise is a liar. So I'm *not* criticizing anyone for suggesting improvements. Instead, I'm criticizing people who choose to not have an honest discussion. People who ask questions, and then tell the experts they're wrong. People who don't read the documentation. People who don't read the messages on this list. People who accuse me of being rude for pointing out this anti-social behaviour. Speaking of which, you *were* warned. Goodbye. Alan DeKok.
To anyone else reading this thread, the explanation from the OpenSSL people is here: https://mta.openssl.org/pipermail/openssl-users/2018-January/007357.html * the intermediate CA has "TLS Web Server Authentication" extended key usage OID * the intermediate CA does NOT have "TLS Web Client Authentication" EKU OID * this intermediate CA signed another, final CA * the final CA which signs the client certificate has BOTH "TLS Web Server Authentication" and "TLS Web Client Authentication". When you have an intermediate CA with usage restrictions, those restrictions apply to *all* certificates derived from that CA. So you can't have a parent CA which says "no EAP-TLS", and then a child CA saying "Yeah, we'll do EAP-TLS anyways". Older versions of OpenSSL didn't enforce these permissions. Version from 1.1.0 onwards do enforce these permissions. And that's the right thing to do. Unfortunately, some commercial vendors produce CAs which are broken and insecure. We *will not* be putting patches into FreeRADIUS to "work around" this issue. The simple reason is that the CAs are wrong, and the commercial vendors are wrong. Anyone who wants to skip these checks is free to edit either the OpenSSL or FreeRADIUS source code, and to build local versions. As for the OP, he's taken to emailing me off-list expressing surprise that he's gone, and claiming that it's not clear what the problem is, and that FreeRADIUS is still wrong. Alan DeKok.
participants (2)
-
Alan DeKok -
Gladewitz, Robert