WPA - AP association Issue

[Bryan Kadzban]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Mr. Maloomnahi wrote:
> 1] Can we use same server-client certificates at AP and STA with 
> different CA?

I'm not entirely sure that I understand what you're asking here.  These
are the requirements of EAP-TLS, in the approximate order that they get
verified:

1) The RADIUS server has a certificate and private key pair.

2) The supplicant has a certificate and private key pair.

3) The certificate at the root of the RADIUS server certificate's issuer
list must be trusted by the client (wpa_supplicant uses the "ca_cert"
and/or "ca_path" options to specify the list of root certs that it
trusts).

4) The certificate at the root of the supplicant's issuer list must be
trusted by the RADIUS server (FreeRADIUS uses the CA_path option to
specify the list of root certs that it trusts).

5) Depending on the RADIUS server configuration, there may be other
requirements (e.g. FreeRADIUS has an option where you can require the CN
in the client's certificate to match the EAP identity that they used),
but these are usually optional.

It looks like your log file shows wpa_supplicant failing at item 3.

> 2] Does the CA of the certificate become important? Can it be made by
> ourselves or procured from some websites and used? [current mode]

Some client and some server software has issues with web site
certificates.  In my experience, they are *not* good to use for EAP-TLS;
I think you're usually better off generating your own, from a root cert
that you control.  But that's just me.

I think wpa_supplicant can probably use either type of cert, but I don't
know which RADIUS server you use, so I don't know what settings it may
require.

> 3] Do you know of any certificate provider who does not charge and is
> easily available to download?

There are no (reputable) cert providers that don't charge anything.  It
costs money for some third party to verify that you really are who you
say you are, and this verification is the whole point of having a cert
signed by a third party.

OpenSSL has a usable CA implementation if you set it up properly.  I'd
look into using that; I know wpa_supplicant works with it, and it's
flexible enough that its certs should be usable by most RADIUS servers
too.

> 4] What do you fel is the issue other than CA error?

Here are the relevant bits in the log (I think):

> SSL: SSL_connect:SSLv3 read server hello A

OK, so wpa_supplicant is reading the server's "hello" message...

> TLS: Certificate verification failed, error 18 (self signed 
> certificate)

...when it sees a certificate whose "Issuer" field has the same name as
the cert's "Subject" field.  This isn't always an error (root certs are
also self-signed), but in this case it seems to be, for some reason.

> depth 0

Ah, this is the problem.  The cert that the RADIUS server is using is
signed by itself ("depth 0" means that it's still looking at the first
cert in the "issued by" chain).  This would be OK if you configure
wpa_supplicant with the path to this cert in its ca_cert option in the
network section, but it's (apparently) not configured that way.

> for '/CN=Sial 
> CA/C=US/ST=Washington/L=Seattle/O=sial.org/emailAddress=jmates at sial.org'

This is the value of the "subject" field in the cert.  These values were
specified when you generated the self-signed cert that the RADIUS server
is using.  The easiest fix is probably to find that file, copy it to
your client, and set ca_cert to the path that you copied it to.

That easy fix may not make it work, though -- you may also have to set
the RADIUS server to accept the cert you're using in wpa_supplicant.
But it'll get you closer.

A real fix would be to generate a self-signed cert whose "basic
constraints" field says it can be a CA, then use that cert's private key
to sign two other certs.  The first cert (and its key) will be used by
the RADIUS server, and the second cert (and its key) will be used by
wpa_supplicant.  Neither of these will be CA certs.  Keep the original
self-signed cert's key safe (I prefer to keep it entirely offline until
it's needed), since with that key an attacker can generate any fake cert
they want, and it'll be accepted by the RADIUS server.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHK7SAS5vET1Wea5wRA0opAKCihVgnQ6zTEY1vjWozAF2Gd/mIOwCgsvnk
o0YnFYB0zQ/AgmKQvDoePqk=
=ilzE
-----END PGP SIGNATURE-----