EAP-TLS with certificate-chain

[Jouni Malinen]

On Tue, Feb 19, 2008 at 02:00:16PM +0100, Faigl Zolt?n wrote:

> First of all, you can find the certificates and certificate chains, 
> cleint and server key files (pwd is ikev2meas) I tried to use until this 
> time at:
> http://www.mcl.hu/~szlaj/certs.zip

It looks like the sub-CAs are using X.509v1 and as such, they do not
include the CA=TRUE basic constraint. I'm not sure whether it is this
part or something else in the certificate that makes OpenSSL not like
the subsubCA certificate ("invalid CA certificate"). Anyway, the
configuration and certificates themselves worked fine for EAP-TLS
authentication when I tested this with wpa_supplicant and the internal
TLS implementation (i.e., no OpenSSL).

You might be able to configure OpenSSL to accept the sub-CAs in their
current form by clearing X509_V_FLAG_X509_STRICT flag from the
verification parameters, but I did not test this. Same change would
likely be needed both for FreeRADIUS and wpa_supplicant. It would
probably be easier to just re-generate the certificates and use X.509v3
for all CA certificates, not just the root.

> So  as I understand, wpa_supplicant configuraion differs from the 
> configuration I used at freeradius, since there, I put the server 
> certificate
> chain into "server certificate file", in trust order, and I put only the 
> rootCA.crt to the "Trusted CAs list" parameter.
> Perhaps, wpa-supplicant-like configuration could also work for 
> freeradius, and if I now, how exactly wpasupplicant configuration works, 
> I will try the same thing with freeradius configuration.

I would expect the same configuration style to work for both as long as
you are using OpenSSL since neither FreeRADIUS nor wpa_supplicant
actually do their own processing on these files. I would assume the main
difference here is whether the other CA certificates are marked as
trusted or not in OpenSSL certificate store. The main need here is to
get all the certificates into the store and have at least the root CA
marked as trusted.

> Could you examplify how to configure up a client-side certificate chain, 
> for example with my sample certificates, if they seem to be good?

I would configure the client key and certificate in
client_cert/client_key and use concatenated list of CAs in ca_cert. In
order to work with the default OpenSSL X.509 verification parameters,
you will likely need to regenerate the sub CA certificates.

> What about the ordering of CA certs in the ca_cert? As I understood this 
> will also be a concatenated PEM format file.

I would not expect the order in ca_cert file to matter. Each certificate
is loaded into the OpenSSL store and OpenSSL should take care of
figuring out the order in this case. If using the client_cert file for
this, the order may be important, but I have not tested that option.

> So, how can I reach that they find the commonly trusted CA for example if
> 
> - server side trusts the following chain: subsubCA1, subCA1, rootCA
> - client side trusts the following chain: subsubCA2, subCA2, rootCA
> (note: server trusts subsubCA1, client trusts subsubCA2, the common CA 
> is rootCA)

Once you get the first test working (i.e., resolve the invalid-CA-cert
issue), this should work by configuring server with
subsubCA1+subCA1+rootCA as trusted certificates and client with
subsubCA2+subCA2+rootCA as trusted certificates. You might be able to
move subsubCA and subCA into the server/client certificate PEM file,
i.e., just mark rootCA as trusted.

During the TLS negotiation, server will then send subsubCA1+subCA1 so
that client does not need to have them pre-configured (and client does
the same for subsubCA2+subCA2).

-- 
Jouni Malinen                                            PGP id EFC895FA