EAP-TLS with certificate-chain

[Faigl Zoltán]

Thank you very much. That solved my problem. Finally I created my subCA 
certificates with the following command:

subCA:
-------

request:
# openssl req -newkey rsa:2048 -sha1 -keyout subCA2.key -out 
subCA2req.pem -config /usr/lib/ssl/openssl.cnf
sign by the higher CA:
# openssl x509 -req -in subCA2req.pem -sha1 -CA rootCA.crt -CAkey 
rootCA.key -CAcreateserial -out subCA2.crt -extfile 
/usr/lib/ssl/openssl.cnf -extensions v3_ca

I don't know why, I had to give explicitly the location of the extfile 
(which is at the default place).

BR,
Zoltan Faigl

Jouni Malinen ?rta:
> 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).
>
>