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

[Matt Bernstein]

At 14:19 +0200 Alan DeKok wrote:

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

I'm not claiming there's no technical solution. On the other hand, our 
departments don't trust each other more in a political way.

We don't really have a university PKI. For eduroam, it's arguable that you 
want your server cert as local to your user base as possible. Our Maths 
users have no reason to trust a server certificate issued by my 
department.

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

OK, thanks: sorry I didn't understand that before.

>> Does it avoid the first layer of proxying?
>
>  It does what I said it does.

OK, so without a single CA it doesn't help us.

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

OK. I think the only way to avoid carrying my filthy patch is to run 
multiple non-virtual servers.

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

Sorry--I'll start a new reply on this point.

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

I'm trying to allow different departments to use eduroam with whatever AAA 
backends they want without the bother of having to run a RADIUS server. My 
institution might be unusual in that there are multiple backends--even 
within our computing service--but the reasons behind this are not 
necessarily technical.

I hope this makes where I'm coming from a little clearer.

Matt