- Freeradius-Users - lists.freeradius.org

freeradius.pip not found
by Hamid Rahman 26 Jan '18

26 Jan '18

can you help me ? when i stopping freeradius with command : /etc/init.d/freeradius stop * Stopping FreeRADIUS daemon freeradius * /var/run/freeradius/freeradius.pid not found... [ OK ] so i try with another command : service freeradius stop stop : unknown instance i'm so confused with this problem 😞 what's wrong ? thanks

2 1

guide on configuring freeradius 3 LDAP
by Douglas C Ward 25 Jan '18

25 Jan '18

Hello, I just joined the list recently, in hopes to get some help in configuring LDAP on my FreeRADIUS server. I have found a lot of documentation for FreeRADIUS v2, dating from 2011 and 2014, etc. But no clear step-by-step to enable LDAP for v3. My server is version 3.0.15. I have worked through the initial setup on the http://wiki.freeradius.org/guide/Getting-Started <http://wiki.freeradius.org/guide/Getting-Started> and was able to connect with “Access-Accept”. But now I want to connect an LDAP server (specifically, a VLDAP server from OneLogin). I have all their docs, and have all the base DN and Bind DN info. But the documentation at http://wiki.freeradius.org/modules/Rlm_ldap <http://wiki.freeradius.org/modules/Rlm_ldap> seem to “start in the middle” for me. It says you "can"… "To enable LDAP in your FreeRADIUS server, you can: • instantiate an ldap module - which sets up the server name, the base DN, etc • authenticate using an ldap module instance - which makes the FreeRADIUS server verify the user's identity in the LDAP directory, usually involving some form of checking the validity of the password • authorize using an ldap module instance - which makes the FreeRADIUS server verify the user's level of authorization in the LDAP directory, usually involving verifying group membership or similar" … but I don’t have enough experience to evaluate those options, or know how to do any of them. So I am looking for a simple “how to enable LDAP on FreeRADIUS 3” that I can follow to get things working, and learn from there. Thank you. —Douglas

6 28

RE: Re: SQL Module: Inconsistent behavior dealing with the escaping backslash
by Kwak Wookjong 25 Jan '18

25 Jan '18

Great, I just tried out your suggestion and it worked as expected and resolved the issue I had. I also agree that we should use "binary" value for the secrets not the "printed form" string value. Given that, Do you think can this fix be part of the next freeradius 3.x.x release? Thanks for the clarification. Best Regards, Wookjong -----Original Message----- From: Freeradius-Users [mailto:freeradius-users-bounces+wookjong.kwak=gemalto.com@lists.freeradius.org] On Behalf Of Alan DeKok Sent: Thursday, January 25, 2018 3:30 PM To: FreeRadius users mailing list <freeradius-users(a)lists.freeradius.org> Subject: [+SPAM+]: Re: SQL Module: Inconsistent behavior dealing with the escaping backslash On Jan 25, 2018, at 3:02 PM, Kwak Wookjong <Wookjong.Kwak(a)gemalto.com> wrote: > > Yes, in the SQL DB, double slashes "\\" are presented. OK. That's good. > ... > (0) EXPAND %{sql: SELECT secret FROM nas WHERE nasname = '%{Packet-Src-IP-Address}'} > (0) --> test\\123 > (0) FreeRADIUS-Client-Secret = test\123 > > ***** up until here, everything seems good as "\\" becomes to "\" That's fine. > ***** problem below when it is converting control list to client field, "\" becomes to "\\", again. > > (0) Converting control list to client fields > (0) ipv4addr = 192.168.99.1 > (0) secret = test\\123 > (0) shortname = Radius Local Test > (0) nas_type = other > Adding client 192.168.99.1/32 with shared secret "test\\123" > > ***** So, when it is adding the client, it is double backslashes. Hmm... the issue is that there are multiple representations of a string. The "binary" value, where the characters just mean themselves, and the "printed" form, where things are escaped, e.g. \n, \\, \t, etc. For various reasons, the dynamic clients have to print the attributes you defined. But, it should just use the "binary" value for secrets, and not use the "printed" form. I think this change should fix it: --- a/src/main/client.c +++ b/src/main/client.c @@ -1341,7 +1341,7 @@ RADCLIENT *client_afrom_request(RADCLIENT_LIST *clients, REQUEST *request) * We could reuse the CONF_PAIR buff, this just keeps things * consistent between client_afrom_cs, and client_afrom_query. */ - *p = talloc_strdup(c, strvalue); + *p = talloc_strdup(c, vp->vp_strvalue); Hopefully that won't break it for anyone else... Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html ________________________________ This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited. E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender. Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.

2 1

RE: Re: Re: SQL Module: Inconsistent behavior dealing with the escaping backslash
by Kwak Wookjong 25 Jan '18

25 Jan '18

Yes, in the SQL DB, double slashes "\\" are presented. Let me put the log with some comments below with ***** to make it clear. id | nasname | shortname | type | ports | secret | server | community | description -----+----------------+----------------------+--------+-------+-------------+--------+----------------+------------- 112 | 192.168.99.1 | Radius Local Test | other | | test\\123 | | | (0) server dynamic_client_server { (0) # Executing section authorize from file /etc/raddb/clients.conf (0) authorize { (0) if ("%{sql: SELECT nasname FROM nas WHERE nasname = '%{Packet-Src-IP-Address}'}") { rlm_sql (sql): Reserved connection (0) (0) Executing select query: SELECT nasname FROM nas WHERE nasname = '192.168.99.1' rlm_sql_postgresql: Status: PGRES_TUPLES_OK rlm_sql_postgresql: query affected rows = 1 , fields = 1 rlm_sql (sql): Released connection (0) (0) EXPAND %{sql: SELECT nasname FROM nas WHERE nasname = '%{Packet-Src-IP-Address}'} (0) --> 192.168.99.1 (0) if ("%{sql: SELECT nasname FROM nas WHERE nasname = '%{Packet-Src-IP-Address}'}") -> TRUE (0) if ("%{sql: SELECT nasname FROM nas WHERE nasname = '%{Packet-Src-IP-Address}'}") { (0) update control { (0) EXPAND %{Packet-Src-IP-Address} (0) --> 192.168.99.1 (0) FreeRADIUS-Client-IP-Address = 192.168.99.1 rlm_sql (sql): Reserved connection (1) (0) Executing select query: SELECT shortname FROM nas WHERE nasname = '192.168.99.1' rlm_sql_postgresql: Status: PGRES_TUPLES_OK rlm_sql_postgresql: query affected rows = 1 , fields = 1 rlm_sql (sql): Released connection (1) (0) EXPAND %{sql: SELECT shortname FROM nas WHERE nasname = '%{Packet-Src-IP-Address}'} (0) --> Radius Local Test (0) FreeRADIUS-Client-Shortname = Radius Local Test rlm_sql (sql): Reserved connection (2) (0) Executing select query: SELECT secret FROM nas WHERE nasname = '192.168.99.1' rlm_sql_postgresql: Status: PGRES_TUPLES_OK rlm_sql_postgresql: query affected rows = 1 , fields = 1 rlm_sql (sql): Released connection (2) (0) EXPAND %{sql: SELECT secret FROM nas WHERE nasname = '%{Packet-Src-IP-Address}'} (0) --> test\\123 (0) FreeRADIUS-Client-Secret = test\123 ***** up until here, everything seems good as "\\" becomes to "\" rlm_sql (sql): Reserved connection (3) (0) Executing select query: SELECT type FROM nas WHERE nasname = '192.168.99.1' rlm_sql_postgresql: Status: PGRES_TUPLES_OK rlm_sql_postgresql: query affected rows = 1 , fields = 1 rlm_sql (sql): Released connection (3) (0) EXPAND %{sql: SELECT type FROM nas WHERE nasname = '%{Packet-Src-IP-Address}'} (0) --> other (0) FreeRADIUS-Client-NAS-Type = other (0) } # update control = noop (0) [ok] = ok (0) } # if ("%{sql: SELECT nasname FROM nas WHERE nasname = '%{Packet-Src-IP-Address}'}") = ok (0) } # authorize = ok (0) } # server dynamic_client_server ***** problem below when it is converting control list to client field, "\" becomes to "\\", again. (0) Converting control list to client fields (0) ipv4addr = 192.168.99.1 (0) secret = test\\123 (0) shortname = Radius Local Test (0) nas_type = other Adding client 192.168.99.1/32 with shared secret "test\\123" ***** So, when it is adding the client, it is double backslashes. Let me know if you need further information. Thanks! Best Regards, WJ -----Original Message----- From: Freeradius-Users [mailto:freeradius-users-bounces+wookjong.kwak=gemalto.com@lists.freeradius.org] On Behalf Of Alan DeKok Sent: Thursday, January 25, 2018 1:18 PM To: FreeRadius users mailing list <freeradius-users(a)lists.freeradius.org> Subject: [+SPAM+]: Re: [+SPAM+]: Re: SQL Module: Inconsistent behavior dealing with the escaping backslash On Jan 25, 2018, at 2:10 PM, Kwak Wookjong <Wookjong.Kwak(a)gemalto.com> wrote: > Thanks for the respond and your suggestion. > But I am still seeing the same problem. (Additional backslash > prepended) > > Even though, using another table (other than NAS) for putting client > information, When, putting the information into attributes, the additional step that you described would be applied. > Then, it would make additional backslash in front of original backslash as it is not *directly* read from the table. > > My question would be how can I make the value read directly from the table as it does for NAS table reading? You can't. You MUST put the value into an attribute. That's how the dynamic clients work. > Or, do we need to check if the escaping is properly done when putting the information into attributes? You need to ensure that the contents of SQL are correct. Which means escaping things properly. Backslashes are special, because they allow escaping. If you want a literal backslash, put "\\" into SQL. Then when you read it from SQL via a SELECT statement, it will be parsed correctly. If this isn't clear, post the *debug output* of the server when it reads a dynamic client from SQL. That will be much clearer. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html ________________________________ This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited. E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender. Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.

2 1

SQL Module: Inconsistent behavior dealing with the escaping backslash
by Kwak Wookjong 25 Jan '18

25 Jan '18

Hi, I have found that the backslash in the shared secret interpreted differently depending on the read_clients option to be set in the /etc/raddb/mods-enable/sql Case 1. When the DB is read while its startup only, by setting read_clients option to be yes, for example, the shared secret, test\123 is read as test\123 and the client is added with having single backslash. Case 2. When the DB is read per each request, by setting read_clients option to be no, the shared secret, test\123 becomes test\\123 and the client is added with having double backslashes. I will put more detail of the Case 2 log, below, $radiusd -X (0) server dynamic_client_server { ........... ........... rlm_sql (sql): Reserved connection (2) (0) Executing select query: SELECT secret FROM nas WHERE nasname = '192.168.99.1' rlm_sql_postgresql: Status: PGRES_TUPLES_OK rlm_sql_postgresql: query affected rows = 1 , fields = 1 rlm_sql (sql): Released connection (2) (0) EXPAND %{sql: SELECT secret FROM nas WHERE nasname = '%{Packet-Src-IP-Address}'} (0) --> test\123 (0) FreeRADIUS-Client-Secret = test\123 rlm_sql (sql): Reserved connection (3) ........... ........... (0) } # server dynamic_client_server (0) Converting control list to client fields (0) ipv4addr = 192.168.99.1 (0) secret = test\\123 (0) shortname = Radius Local Test (0) nas_type = other Adding client 192.168.99.1/32 with shared secret "test\\123" in bold, you will see the additional backslash has added when it is converting control list to client fields. However, in Case 1, It doesn't even print out the log from rlm_sql, So, I assume that it is adding the client information from a different path with the different logic. As a result, the client is added with shared secret test\123, in this case. Suppose, I want to set the read_clients option to be "no", as the shared secret can be modified at any time and it should be reflected at every request, why can't both cases have the same way of treating escaping backslash? Thanks! Best Regards, WJ ________________________________ This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited. E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender. Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.

2 3

Howto provide free airtime or no accounting in night for quota base user
by JAHANZAIB SYED 25 Jan '18

25 Jan '18

Scenario: 1) Mikrotik as NAS 2) FREERADIUS as billing server Q1- Suppose, we have few quota base services and our internet bandwidth generally remains empty in night. therefore we want to provide free internet usage by bypassing quota counters in night. like from 8pm till 8am. Q2- This might not be related to FR. Some ISP's provide unlimited data access for FB,YT, whatsapp and other specific without any limit? how they do this? how they bypass accounting for such contents? from there NAS level or via using some magical code in FR ? Regards, Jz <http:///>

4 5

WISPr-Bandwidth-Max-Up Problem.
by Sergen Çolak 25 Jan '18

25 Jan '18

Hello to everyone I am using Freeradius version 2.2.5. I use Coovachilli with it. I'm having a problem when I want to speed limit the user. I am writing my user on the radcheck table. 1E1 Password == 00.00.0000 I am writing the WISPr values in the radreply table. 1E1 WISPr-Bandwidth-Max-Up: = 1048576 1E1 WISPr-Bandwidth-Max-Down: = 1048576 I am doing Speedtest when I sign in with 1E1 User. Download Bandwidth is working fine. 1 Mbps but the Upload Bandwidth is unlimited. If there is any that can help, I can give more detailed information. Thank you.

3 2

rlm_perl
by Bassem Mettichi 25 Jan '18

25 Jan '18

Hello, please could any one tell us how to compile rlm_perl on centos 7 with freeradius 3.0.16, i need to know the developpement libraires to install with perl on centos to compile this module with freeradius because i was obliged to do: yum install perl* to make this module working for me but this will install a lot of packages that i don't need. thanks in advance Best Regards Mettichi Bassem

2 1

Problem after upgrade 3.0.4 -> 3.0.13
by BASSAGET Cédric 25 Jan '18

25 Jan '18

Hello, I'm using freeradius on centos 7 to do AAA for L2TP/PPP services. I've upgraded one of my two radius servers from official Centos Repos, and since this upgrade, users are not able to authenticate. here's the interesting part of "radiusd -Xx" : Thu Jan 18 09:45:52 2018 : Debug: radiusd: #### Loading Virtual Servers #### Thu Jan 18 09:45:52 2018 : Debug: server { # from file /etc/raddb/radiusd.conf Thu Jan 18 09:45:52 2018 : Debug: } # server Thu Jan 18 09:45:52 2018 : Debug: server domain.dslnet.fr { # from file /etc/raddb/sites-enabled/domain-lns Thu Jan 18 09:45:52 2018 : Debug: # Loading authenticate {...} Thu Jan 18 09:45:52 2018 : Debug: digest Thu Jan 18 09:45:52 2018 : Debug: eap Thu Jan 18 09:45:52 2018 : Debug: # Loading authorize {...} Thu Jan 18 09:45:52 2018 : Debug: policy filter_username { Thu Jan 18 09:45:52 2018 : Debug: if (!&User-Name) { Thu Jan 18 09:45:52 2018 : Debug: noop Thu Jan 18 09:45:52 2018 : Debug: } Thu Jan 18 09:45:52 2018 : Debug: if (&User-Name =~ / /) { Thu Jan 18 09:45:52 2018 : Debug: update { Thu Jan 18 09:45:52 2018 : Debug: &reply:Reply-Message += "Rejected: Username contains whitespace" Thu Jan 18 09:45:52 2018 : Debug: } Thu Jan 18 09:45:52 2018 : Debug: reject Thu Jan 18 09:45:52 2018 : Debug: } Thu Jan 18 09:45:52 2018 : Debug: if (&User-Name =~ /@.*@/) { Thu Jan 18 09:45:52 2018 : Debug: update { Thu Jan 18 09:45:52 2018 : Debug: &reply:Reply-Message += "Rejected: Multiple @ in username" Thu Jan 18 09:45:52 2018 : Debug: } Thu Jan 18 09:45:52 2018 : Debug: reject Thu Jan 18 09:45:52 2018 : Debug: } Thu Jan 18 09:45:52 2018 : Debug: if (&User-Name =~ /\\.\\./) { Thu Jan 18 09:45:52 2018 : Debug: update { Thu Jan 18 09:45:52 2018 : Debug: &reply:Reply-Message += "Rejected: Username contains ..s" Thu Jan 18 09:45:52 2018 : Debug: } Thu Jan 18 09:45:52 2018 : Debug: reject Thu Jan 18 09:45:52 2018 : Debug: } Thu Jan 18 09:45:52 2018 : Debug: if (&User-Name =~ /@/ && !&User-Name =~ /(a)(.+)\\.(.+)$/) { Thu Jan 18 09:45:52 2018 : Debug: update { Thu Jan 18 09:45:52 2018 : Debug: &reply:Reply-Message += "Rejected: Realm does not have at least one dot separator" Thu Jan 18 09:45:52 2018 : Debug: } Thu Jan 18 09:45:52 2018 : Debug: reject Thu Jan 18 09:45:52 2018 : Debug: } Thu Jan 18 09:45:52 2018 : Debug: if (&User-Name =~ /\\.$/) { Thu Jan 18 09:45:52 2018 : Debug: update { Thu Jan 18 09:45:52 2018 : Debug: &reply:Reply-Message += "Rejected: Realm ends with a dot" Thu Jan 18 09:45:52 2018 : Debug: } Thu Jan 18 09:45:52 2018 : Debug: reject Thu Jan 18 09:45:52 2018 : Debug: } Thu Jan 18 09:45:52 2018 : Debug: if (&User-Name =~ /(a)\\./) { Thu Jan 18 09:45:52 2018 : Debug: update { Thu Jan 18 09:45:52 2018 : Debug: &reply:Reply-Message += "Rejected: Realm begins with a dot" Thu Jan 18 09:45:52 2018 : Debug: } Thu Jan 18 09:45:52 2018 : Debug: reject Thu Jan 18 09:45:52 2018 : Debug: } Thu Jan 18 09:45:52 2018 : Debug: } Thu Jan 18 09:45:52 2018 : Debug: preprocess Thu Jan 18 09:45:52 2018 : Debug: auth_log Thu Jan 18 09:45:52 2018 : Debug: chap Thu Jan 18 09:45:52 2018 : Debug: mschap Thu Jan 18 09:45:52 2018 : Debug: digest Thu Jan 18 09:45:52 2018 : Debug: suffix Thu Jan 18 09:45:52 2018 : Debug: eap Thu Jan 18 09:45:52 2018 : Debug: files Thu Jan 18 09:45:52 2018 : Debug: sql Thu Jan 18 09:45:52 2018 : Debug: expiration Thu Jan 18 09:45:52 2018 : Debug: logintime Thu Jan 18 09:45:52 2018 : Debug: pap Thu Jan 18 09:45:52 2018 : Debug: # Loading preacct {...} Thu Jan 18 09:45:52 2018 : Debug: preprocess Thu Jan 18 09:45:52 2018 : Debug: policy acct_unique { Thu Jan 18 09:45:52 2018 : Debug: if ("%{string:Class}" =~ /ai:([0-9a-f]{32})/) { Thu Jan 18 09:45:52 2018 : Debug: update { Thu Jan 18 09:45:52 2018 : Debug: &Acct-Unique-Session-Id := "%{md5:%{1},%{Acct-Session-ID}}" Thu Jan 18 09:45:52 2018 : Debug: } Thu Jan 18 09:45:52 2018 : Debug: } Thu Jan 18 09:45:52 2018 : Debug: else { Thu Jan 18 09:45:52 2018 : Debug: update { Thu Jan 18 09:45:52 2018 : Debug: &Acct-Unique-Session-Id := "%{md5:%{User-Name},%{Acct-Session-ID},%{%{NAS-IPv6-Address}:-%{NAS-IP-Address}},%{NAS-Identifier},%{NAS-Port-ID},%{NAS-Port}}" Thu Jan 18 09:45:52 2018 : Debug: } Thu Jan 18 09:45:52 2018 : Debug: } Thu Jan 18 09:45:52 2018 : Debug: } Thu Jan 18 09:45:52 2018 : Debug: suffix Thu Jan 18 09:45:52 2018 : Debug: files Thu Jan 18 09:45:52 2018 : Debug: # Loading accounting {...} Thu Jan 18 09:45:52 2018 : Debug: sql Thu Jan 18 09:45:52 2018 : Debug: unix Thu Jan 18 09:45:52 2018 : Debug: exec Thu Jan 18 09:45:52 2018 : Debug: attr_filter.accounting_response Thu Jan 18 09:45:52 2018 : Debug: # Loading post-proxy {...} Thu Jan 18 09:45:52 2018 : Debug: eap Thu Jan 18 09:45:52 2018 : Debug: # Loading post-auth {...} Thu Jan 18 09:45:52 2018 : Debug: if (!"%{Packet-Src-IP-Address}" == 192.168.156.9 && !"%{Packet-Src-IP-Address}" == 192.168.155.9) { Thu Jan 18 09:45:52 2018 : Debug: reply_log Thu Jan 18 09:45:52 2018 : Debug: sql Thu Jan 18 09:45:52 2018 : Debug: } Thu Jan 18 09:45:52 2018 : Debug: exec Thu Jan 18 09:45:52 2018 : Warning: /etc/raddb/policy.d/eap[79]: Please change attribute reference to '&Reply-Message !* ...' Thu Jan 18 09:45:52 2018 : Debug: policy remove_reply_message_if_eap { Thu Jan 18 09:45:52 2018 : Debug: if (&reply:EAP-Message && &reply:Reply-Message) { Thu Jan 18 09:45:52 2018 : Debug: update { Thu Jan 18 09:45:52 2018 : Debug: &reply:Reply-Message !* ANY Thu Jan 18 09:45:52 2018 : Debug: } Thu Jan 18 09:45:52 2018 : Debug: } Thu Jan 18 09:45:52 2018 : Debug: else { Thu Jan 18 09:45:52 2018 : Debug: noop Thu Jan 18 09:45:52 2018 : Debug: } Thu Jan 18 09:45:52 2018 : Debug: } Thu Jan 18 09:45:52 2018 : Warning: /etc/raddb/policy.d/eap[79]: Please change attribute reference to '&Reply-Message !* ...' Thu Jan 18 09:45:52 2018 : Debug: } # server domain.dslnet.fr When a user tries to authenticate, I get : Debug: (23) suffix: Checking for suffix after "@" Debug: (23) suffix: Looking up realm "domain.dslnet.fr" for User-Name = " user(a)domain.dslnet.fr" Debug: (23) suffix: No such realm "domain.dslnet.fr" Can anybody tell me why it does not find the realm ? Does radiusd look in sites-enabled/ or in proxy.conf ? I have no problems with the same config files on 3.0.4 Regards Cédric

5 7

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