TLS configuration

Matthew Newton mcn4 at
Tue Mar 6 15:04:27 CET 2012

On Sun, Mar 04, 2012 at 10:46:00AM +0100, Alan DeKok wrote:
>   I've pulled most of the coce in, with some minor changes.

OK, thanks!

I'm pondering a few more small things -

I've tested templates with the tls config, and it works fine - so
I wonder if it's worth an example in the templates.conf for tls?
Not sure how much would normally be shared to be worth it, though.
Server certificate and a few other bits, maybe.

On PEAP/TTLS client certificates, I think it would now be nice to
have a

  require_client_cert = yes

option in the peap {} and ttls {} sections. Maybe that can be
overridden by EAP-TLS-Require-Client-Cert (or maybe even
EAP-PEAP-Require-* and EAP-TTLS-Require-*, although not sure if
that's worth it). I'll put together a patch for the option to
peap/ttls if it's worth it.

There's a comment in the code about the
EAP-TLS-Require-Client-Cert needing fixing, but I don't know what
the thoughts on that were at the time?

I'm still not 100% sure on the tls-config tls-common directive. It
seemed the best way a few days ago, because the eap module treats
all conf_sections inside eap {} as eap-type modules to load.
Having tls-config as a 'virtual type' meant it was easier to
avoid. I'm starting to look at it and think it's not that clean,

The following might tidy it up.

eap {
  common_settions = here
  tls-config {
    common { ... }
  tls {
    tls = common
  peap { ... }
  gtc { ... }
  md5 { ... }

Possibly also have a 'types {}' section for all the eap-types to
go in, to then avoid having the exception for tls-config that's
not a sub-module, as the eap code could iterate over that knowing
it will only contain modules (a bit like the main modules{}



Matthew Newton, Ph.D. <mcn4 at>

Systems Architect (UNIX and Networks), Network Services,
I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom

For IT help contact helpdesk extn. 2253, <ithelp at>

More information about the Freeradius-Devel mailing list