[awful patch] "Multiple levels of TLS nesting is invalid."

[Alan DeKok]

Matt Bernstein wrote:
> We will have multiple server certificates; our departments are rather
> independent here.

  Ugh.  There's not really any good reason for this.  If the
departmental certs are signed by a university CA, then you can still get
away with one server instance.

>>         update control {
>>             Virtual-Server = "%{Realm}"
>>         }
> 
> What does this achieve?

  What I said in my previous message:

  If you have one server certificate for TTLS, you don't need this extra
layer of nesting.  The TTLS && PEAP modules will look for a *dynamic*
definition of the virtual server for the inner-tunnel.

> Does it avoid the first layer of proxying?

  It does what I said it does.

> My set-up is working without it, AFAICT:

  Yes, I did read your message.  I did see the point where you said your
configuration worked.  Maybe I was trying to describe how you could
acheive your goal *without* source code patches.

> Maybe the inner eap config can be the same for the "inner" virtual
> servers, but the server{} blocks will necessarily be different.

  Well, yes.  That's the point of virtual servers.

> I have run into another bug: if I instantiate rlm_ldap in my servers
> "dcs-inner" and "maths-inner", it seems to use the base DN for
> "maths-inner" (instantiated second) for queries from "dcs-inner".

  As always, debug mode.

> Am I just being too weird and hairy? Or should I use a separate radiusd
> and raddb for each subrealm, as is the case with my production
> FreeRADIUS 1.1 set-up?

  It's a little complicated.  Unnecessarily so, IMHO.

  Alan DeKok.