Can I use two or more freeradius server certificates for the same virtual site?

[work vlpl]

Hello.

Certificates have limited lifespan. And when certificate will expire,
there is a probability that new certificate will not be trusted by
clients with old configuration. I am searching the way to smooth it.
One of the ideas is to configure freeradius to use two server
certificates. They will have different expiration date. So the old
clients will be able to use old certificate and the new clients or
clients with updated configuration will be able to accept new server
certificate.

I tried to place two different eap modules one by one like

...
eap
eap2
...

In hope that this will work like it works with modules with different
types (chap -> mschap -> pap). If client does not accept server
certificate from the first module, then try to send certificate from
the second module. But eap module is not simple and is called multiply
times (Challenge response) to setup eap session, thus this approach
does not work.

And in radius request I don't have any attributes that could help me
to narrow request to the specific eap module.

So, is it possible to use two or more freeradius server certificates?
Or maybe somebody have ideas how to configure eap modules to do it.

--
Vladimir
-
List info/subscribe/unsubscribe? See http://www.freeradi

[Alan DeKok]

On Nov 1, 2018, at 7:07 AM, work vlpl <***@gmail.com> wrote:
> Certificates have limited lifespan. And when certificate will expire,
> there is a probability that new certificate will not be trusted by
> clients with old configuration.

Which certificate do you mean? The client trusts the CA cert. The server cert is derived from that.

> I am searching the way to smooth it.
> One of the ideas is to configure freeradius to use two server
> certificates. They will have different expiration date. So the old
> clients will be able to use old certificate and the new clients or
> clients with updated configuration will be able to accept new server
> certificate.

If you're using the same CA cert, just change the server certificate. All clients should accept the new server certificate automatically.

> So, is it possible to use two or more freeradius server certificates?

Not really in the way that you're asking. Because it shouldn't be necessary.

Alan DeKok.


-
List info/subscribe/unsubscribe?

[work vlpl]

On Thu, 1 Nov 2018 at 18:57, Alan DeKok <***@deployingradius.com> wrote:

> Which certificate do you mean? The client trusts the CA cert. The server cert is derived from that.

The server certificate, that configured by option `certificate_file`
in `tls-config tls-common` section (eap module)

> If you're using the same CA cert, just change the server certificate. All clients should accept the new server certificate automatically.

Yes, I know about it. But in my case I can not issue new server
certificate from the same CA. That CA was bought by other CA, and now
new certificates are signed with different root certificate. This
cause some problems. Clients that verify server certificate using CA
certificate that stored in radius configuration, now has broken trust
chain.

The idea of using two certificates aims to avoid similar problems in the future.

> Not really in the way that you're asking. Because it shouldn't be necessary.

Ok, I got it.
Thank you very much for your answers.

--
Vladimir
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/li

[Alan DeKok]

On Nov 1, 2018, at 9:52 AM, work vlpl <***@gmail.com> wrote:
> Yes, I know about it. But in my case I can not issue new server
> certificate from the same CA. That CA was bought by other CA, and now
> new certificates are signed with different root certificate.

Ugh. That's not nice.

> This
> cause some problems. Clients that verify server certificate using CA
> certificate that stored in radius configuration, now has broken trust
> chain.

The problem is that TLS doesn't really allow for what you want. When EAP-TLS (or PEAP or TTLS) starts up, there's no way for the client to signal which CA root it wants.

Instead, what happens is this (roughly speaking)

client: let's do TLS!

server: Sure, here's my CA and server cert!

client: Uh... not what I wanted, goodbye!

The only way to signal which CA you want is by some other method. i.e. changing the outer identities, as Christian suggested.

Or, you could have a list of which systems (i.e. MAC address) use which certificates. And then do:

if (system is in group 1) {
eap with old Ca cert
}
else {
eap with new CA cert
}

There aren't really many other options. TLS 1.3 is supposed to fix that, I think, but it's a long way from wide-spread use.

Alan DeKok.


-
List info/subscribe/unsubscribe? See http://ww

[work vlpl]

> The only way to signal which CA you want is by some other method. i.e. changing the outer identities, as Christian suggested.

I understand it, and use it.

Unfortunately, it will not work for current clients. They should be
reconfigured (changed anonymous identity) to support it.

Anyway, thanks to both of you, for your answers.
--
Vladimir
-
List info/subscribe/unsubscribe? See http://www.fr

[Brian Julin]

Alan DeKok <***@deployingradius.com> wrote:

> client: let's do TLS!
>
> server: Sure, here's my CA and server cert!
>
> client: Uh... not what I wanted, goodbye!
>
> The only way to signal which CA you want is by some other method. i.e. changing the outer identities, as Christian suggested.

Just a note for edification/general interest, in the case of non-Windows IPSEC, there are modes where
clients can send requests for desired CAs over the IKE protocol. Doesn't help for WiFi unless maybe if
you are doing Open+IPSEC setups.

(Windows can do that mode too but the client doesn't do sufficient security checks in that mode,
you have to tunnel PEAP to get CN validation)

-
List info/subscribe/unsubscribe? See http://www.freeradiu

[Thor Spruyt]

----- Original Message -----
> From: "work vlpl" <***@gmail.com>
>
> Yes, I know about it. But in my case I can not issue new server
> certificate from the same CA. That CA was bought by other CA, and now
> new certificates are signed with different root certificate. This
> cause some problems. Clients that verify server certificate using CA
> certificate that stored in radius configuration, now has broken trust
> chain.

Your CA should give you ample time for such a change.
Clients should be reocnfigured to trust both CAs before you start using the certificate by the new CA.

What you could try to do given your situation is to keep track of which client accepts which certificate and offer them that one.

Regards,
Thor
-
List info/subscribe/unsubscribe? See http://www.freeradi

[Christian Strauf]

Hi Vladimir,

> In hope that this will work like it works with modules with different
> types (chap -> mschap -> pap). If client does not accept server
> certificate from the first module, then try to send certificate from
> the second module. But eap module is not simple and is called multiply
> times (Challenge response) to setup eap session, thus this approach
> does not work.
this approach doesn't work since the EAP process will fail as soon as the client sees a certificate signed by an unknown CA.

Your problem is well known though. It occurs when (for some reason) a CA certificate needs to be changed or becomes invalid. For security reasons you normally trust only one CA on a client and only accept server certs signed by that particular CA. However, there's a method that works for tunneled EAP methods like PEAP or EAP-TTLS. You can "signal" what CA a client expects by using different outer (anonymous) identities. For example you could use "***@...." for clients that trust the old CA and "***@..." for those that trust the new CA. You can then define the two modules "eap" an "eap2" and do something like

if ( &User-Name == "***@your-realm" ) {
eap {
ok = return
}
} else {
eap2 {
ok = return
}
}

(you should probably not use "else" but rather use two "if" statements; but you get what I mean) in the authorize section of the site for which you need to offer server certs signed by different CAs.

Kind regards,
Christian
--
Dipl.-Math. Christian Strauf
Clausthal Univ. of Technology E-Mail: ***@rz.tu-clausthal.de
Rechenzentrum Web: www.rz.tu-clausthal.de
Erzstraße 18 Tel.: [phone] Fax: -992086
D-38678 Clausthal-Zellerfeld

[Christian Strauf]

P. S.:

Forgot to mention: in your site configuration you also need to place this in the authenticate section:

Auth-Type eap {
eap
}

Auth-Type eap2 {
eap2
}

Sorry.

[work vlpl]

On Thu, 1 Nov 2018 at 19:12, Christian Strauf <***@rz.tu-clausthal.de> wrote:

Thank you for your reply.
I know about this feature - send different server certificate to the
clients from different realms, and I use it. But my problem is another
case.
--
Vladimir
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.

[Christian Strauf]

> I know about this feature - send different server certificate to the
> clients from different realms, and I use it. But my problem is another
> case.
I'm not talking about different realms. The realms are the same, you merely use different outer identities.

To my knowledge there's no other way to have two different server certificates within the same EAP module. With respect to TLS it wouldn't make sense.

Christian

[Christian Strauf]

> I'm not talking about different realms. The realms are the same, you merely use different outer identities.
To be precise: different user names for the outer identity while using the same realms.

Christian