- Freeradius-Users - lists.freeradius.org

Solved: After Upgrade from freeradius 2 to 3 (Debian 8 - 9): TLS Alert write:fatal:unsupported certificate
by Gladewitz, Robert 24 Jan '18

24 Jan '18

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(a)dbfz.de>; FreeRadius users mailing list <freeradius-users(a)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(a)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(a)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(a)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(a)lists.freeradius.org>; Boris Lytochkin <lytboris(a)yandex-team.ru>; Gladewitz, Robert <Robert.Gladewitz(a)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=bu… (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(a)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(a)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

2 4

Seek some informations for dynamic vlan attribution on freeradius V3 based on LDap.
by Yaël Rozanes 24 Jan '18

24 Jan '18

Hello everyone, I apologize in advance for possible English mistakes. I set up à Freeradius server ( version 3.0.12 ) on debian, it is coupled to an ldap for the authentification. This part works correctly, but i want to use the description field of my Ldap ( or an other field ) as I was using it in freeradius V2 to associate users with a Vlan. I was using "chekItem LDAP-Desc description" on freeradius V2 in the file ldap.attrmap. I didn't find an equivalent solution on freeradius V3, and I would have liked to know if there was any documentation on dynamic allocation of Vlan or if this solution was possible on Freeradius V3? I found my first solution on this Website : https://www.unix-experience.fr/2012/freeradius-serveur-radius-opensource/ i'v already read the guides on wiki-radius like the eduroam conf, but but it wasn't the right solution for me. thanks in advance for your answers, and apologize again for the mistakes i've made, im a nweebie in the IT world.

2 1

[RP #2160] EAP-TLS | OCSP with Intermediate CA
by Isaac Boukris 24 Jan '18

24 Jan '18

Hello, Following up on the pull-request. The scenario I am testing is when a client issue a certificate from a sub-ca which is not trusted (ca_file only points to root CA). In such case, the client must send its issuer certificate along in order to complete the chain and get verified. This works ok, however the OCSP verification is skipped in such case because we fail get issuer certificate (even if softfail is no). The first patch fix the above and treats this error as a soft failure. The second one attempts to get the issuer-certificate differently which works for this scenario (where the issuer isn't trusted). Note that eapol_test, unlike some other supplicants, doesn't send all the certificates from the client_cert file. However, it can be done with a little patch as follows: # git diff diff --git a/src/crypto/tls_openssl.c b/src/crypto/tls_openssl.c index ce73848..d180343 100644 --- a/src/crypto/tls_openssl.c +++ b/src/crypto/tls_openssl.c @@ -2653,10 +2653,9 @@ static int tls_connection_client_cert(struct tls_connection *conn, return 0; } - if (SSL_use_certificate_file(conn->ssl, client_cert, - SSL_FILETYPE_PEM) == 1) { + if (SSL_use_certificate_chain_file(conn->ssl, client_cert)) { ERR_clear_error(); - wpa_printf(MSG_DEBUG, "OpenSSL: SSL_use_certificate_file (PEM)" + wpa_printf(MSG_DEBUG, "OpenSSL: SSL_use_certificate_chain_file (PEM)" " --> OK"); return 0; Configuration example: network={ ssid="1x-test" key_mgmt=IEEE8021X eap=TLS identity="bob" ca_cert="freeradius_ca_cert" client_cert="client_cert_and_issuer" private_key="key" private_key_passwd="pwd" eapol_flags=3 } Thanks, Isaac B.

2 4

Hotels Database with freeradius
by Muhammed Buvaydani 24 Jan '18

24 Jan '18

I want to know how can I integrated freeradius server with ready sql/oracle hotels database The authentication will done by room number and guest name . So if new customer have account in hotel he can use wifi by entering room number and his name and when he make checkout he can not connect to wifi . So how can I do that I searched alote without result . Specially every hotel has different database and tables name .

1 0

Proxy problem when switching from version2 to version3
by Bornemann, Hans 24 Jan '18

24 Jan '18

Hi, when switching to version 3 I have a little problem to find my misconfiguration. the home server says: access rejected because the freeradius sends: >From wireshark on home server: Fail: Extensible Authentication Protocol Code: Response (2) ID: 2 Length: 8 Type: Legacy Nak ( Response Only) (3) Desired Auth Type: protected EAP ( EAP-PEAP) (25) OK with version 2: Extensible Authentication Protocol Code: Response (2) ID: 10 Length: 70 Type: MS-Authentication EAP (EAP-MS-AUTH) (26) EAP-MS-CHAP-v2 OpCode: Response (2) EAP-MS-CHAP-v2 Id: 10 EAP-MS-CHAP-v2 ..... ..... EAP-MS-CHAP-v2 Name: radius@itmc Where do I have to look in the configuration? Regards Hans Hans Bornemann Abteilung Datanet Technische Universität Dortmund ITMC Otto-Hahn-Str. 12 44227 Dortmund Tel.: +49 231-755 2132 hans.bornemann(a)tu-dortmund.de www.itmc.tu-dortmund.de Wichtiger Hinweis: Die Information in dieser E-Mail ist vertraulich. Sie ist ausschließlich für den Adressaten bestimmt. Sollten Sie nicht der für diese E-Mail bestimmte Adressat sein, unterrichten Sie bitte den Absender und vernichten Sie diese Mail. Vielen Dank. Unbeschadet der Korrespondenz per E-Mail, sind unsere Erklärungen ausschließlich final rechtsverbindlich, wenn sie in herkömmlicher Schriftform (mit eigenhändiger Unterschrift) oder durch Übermittlung eines solchen Schriftstücks per Telefax erfolgen. Important note: The information included in this e-mail is confidential. It is solely intended for the recipient. If you are not the intended recipient of this e-mail please contact the sender and delete this message. Thank you. Without prejudice of e-mail correspondence, our statements are only legally binding when they are made in the conventional written form (with personal signature) or when such documents are sent by fax.

2 4

mod_auth_radius
by Muhammed Buvaydani 23 Jan '18

23 Jan '18

Hello Mr Alan Thank you very much for your help and wish to help me I working on freeradius management system and every things go fine , I integrated captive portal with fortigate firewall , but if my customer has different type of firewall, what I do? Must I integrate captive portal for another firewall ? I found mod_auth_radius modul and I think this module will convert my apach server as NAS so it can working instead of firewall right? How can I use it ?

2 1

Track User's Visited Websites
by Muhammed Buvaydani 23 Jan '18

23 Jan '18

How can I track user's visited websites through freeradius server . İs there any way to store visited websites by username or mac address I searched alote without result . Please help me

2 1

Radius, Database and integrated Captive-Portal. Appliance Hotspot BreldoItalia
by bruno d'ambrosio 23 Jan '18

23 Jan '18

Dear users, round to the internet I noticed this wonderful company the "BreldoItalia Engieering Wireless" that deals with the engineering and development of Stand-Alone Hotspot Appliances, Wi-Fi indoor/outdoor products and Appliance Firewall for data network security. The main part that I could not take my eyes off is their firmware "Breldo O.S", a simple firmware where used as a hotspot system integrates a radius server, database and captive-portal. In fact, their Hotspot Appliances do not use any external server or cloud, the whole hotspot system works locally on their appliances. For more information visit their website: www.breldoitalia.it<http://www.breldoitalia.it> Best Regard Bruno D'Ambrosio

5 7

Re: Radius, Database and integrated Captive-Portal. Appliance Hotspot BreldoItalia
by Nathan Ward 23 Jan '18

23 Jan '18

> On 23/01/2018, at 11:55 PM, bruno d'ambrosio <brunodambrosio2011(a)hotmail.it <mailto:brunodambrosio2011@hotmail.it>> wrote: > > Hello Dear User > As I understand it, first the project was called BreldoItalia Wi-Fi Hotspot, now called BreldoItalia Engineering Wireless. > They have designed a nice stand-alone hotspot system to be tried absolutely. > I'm just saying that if you can use their product to see how their system works it's not bad. > I'm not advertising even I know them to BreldoItalia. You say here “It’s not bad” - which means you must have used it. But you also say: > On 23/01/2018, at 11:04 PM, bruno d'ambrosio <brunodambrosio2011(a)hotmail.it <mailto:brunodambrosio2011@hotmail.it>> wrote: > > I've never tried the BreldoItalia Hotspot system In English there is an idiom, “digging yourself in to a hole”. It refers to when you get stuck in a story or a lie or some sort of bad situation (a “hole”) and you keep talking trying to talk your way out of it, when you are actually making it worse for yourself. I don’t know if it’s a common phrase, but a friend of mine says “dig up” as a joke, referring to this. It means: “you’re in a hole, keep talking/digging out of it” - obviously if you’re in a hole, keeping digging/talking doesn’t get you out, it just gets you deeper in to it! We all know what it means, we accept that we’ve made a mistake or similar, and we all have a laugh about how silly we were to think we could explain our way out of it. We would also *stop* trying to “dig” our way out of the hole. So, to you I say: “dig up”. I won’t say anything more. -- Nathan Ward

1 0

Web Access Logs
by Muhammed Buvaydani 23 Jan '18

23 Jan '18

Hello I working in freeradius management system and every things go fine. my boss asked me to get all websites that every users who connected to our WiFi has visited . I searched about that for many days without result . I think freeradius does not supports this feature . any way How can I solve this problem .

1 0