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
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
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
