radsecproxy January 2021

radsecproxy@lists.nordu.net

3 participants
3 discussions

Adding support for dynamic authorisation messages (CoA/Disconnect)
by Harshit Jain 29 Apr '21

29 Apr '21

Hello, I was looking to add support for Dynamic Authorization Messages - Change of Authority (CoA) and Disconnect messages - to radsecproxy. RFC for this can be found here - https://tools.ietf.org/html/rfc5176 . Before diving headfirst, I wanted to ask if it is already on the roadmap or if there has been a design discussion that I can read up on. Thanks and regards, Harshit Jain

2 18

CACertificatePath does not seem to be working
by Imtiyaz Mohammad 20 Jan '21

20 Jan '21

Hi, In my setup, I am trying to verify the working of *CRLCheck *option in the tls config block of radsecproxy. I currently have a CACertificateFile statement in the radsecproxy config that is pointing to a ca.pem. I created a CRL using the ca.pem and ca.cnf and issued a SIGHUP to radsecproxy only to find the following error message:- Jan 18 11:31:56 2021: verify error: num=3:unable to get certificate CRL:depth=0:/C=FR/ST=Radius/O=Example Inc./CN= 127.0.0.1/emailAddress=admin(a)example.org Jan 18 11:31:56 2021: tlsconnect: SSL connect to 127.0.0.1 failed: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed Looked like radsecproxy tried to pick up the CRL file but it could not find it where it was expecting it. Hence I removed the CACertificateFile option from the TLS block of the config file and added CACertificatePath option that points to the directory that has the CA and CRL files and now I am getting this error. What am I missing here ? ....Jan 19 08:05:36 2021: tlsconnect: connecting to 127.0.0.1 Jan 19 08:05:36 2021: connecttcphostlist: trying to open TCP connection to 127.0.0.1 port 2083 Jan 19 08:05:36 2021: Connection up Jan 19 08:05:36 2021: connecttcphostlist: TCP connection to 127.0.0.1 port 2083 up Jan 19 08:05:36 2021: verify error: num=19:self signed certificate in certificate chain:depth=1:/C=FR/ST=Radius/L=Somewhere/O=Example Inc./emailAddress=admin(a)example.org/CN=Example Certificate Authority Jan 19 08:05:36 2021: tlsconnect: SSL connect to 127.0.0.1 failed: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed Jan 19 08:05:36 2021: tlsconnect: SSL connect to 127.0.0.1 failed Jan 19 08:05:36 2021: Next connection attempt to 127.0.0.1 in 60s ....Jan 19 08:06:36 2021: tlsconnect: connecting to 127.0.0.1 Thanks Imtiyaz

2 2

Logs are not being written to options.logdestination when -f (foreground) is passed to radsecproxy
by Imtiyaz Mohammad 05 Jan '21

05 Jan '21

Hello Fabian, We have noticed that the log destination option in the radsecproxy configuration file is completely ignored when radsecproxy is made to run in the foreground with the -f argument. Looking at the code ( snippet pasted below ), it looks to be something intentional. In radsecproxy.c radsecproxy_main() { //// if (!foreground) { debug_set_destination(options.logdestination ? options.logdestination : "x-syslog:///", LOG_TYPE_DEBUG); if (options.ftickssyslogfacility) { debug_set_destination(options.ftickssyslogfacility, LOG_TYPE_FTICKS); free(options.ftickssyslogfacility); } } } However, we think that if the configuration file has a log destination, it should override any other directive and we should write logs to that log destination instead of using* -f* as a toggle to write to STDOUT vs the log destination. Let us know what you think about this ? Here is my suggested fix , change the above snippet of code to:- if (options.logdestination) { debug_set_destination(options.logdestination, LOG_TYPE_DEBUG); free(options.logdestination); } else if (!foreground) { debug_set_destination("x-syslog:///", LOG_TYPE_DEBUG); } if (options.ftickssyslogfacility) { debug_set_destination(options.ftickssyslogfacility, LOG_TYPE_FTICKS); free(options.ftickssyslogfacility); } Thanks, Imtiyaz

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

radsecproxy January 2021