WPA - AP association Issue

[Bryan Kadzban]

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

Mr. Maloomnahi wrote:
> 1] Hostapd is running as the RADIUS server on a particular IP with 
> ca-cert.pem, server.pem, server.prv [key] generated using the openSSL
> from /usr/bin

So far so good...

> 2] WPA is running as a STA on another PC with ca-cert.pem,
> server.pem, server.prv generated using the openSSL from /usr/bin

Hang on, that doesn't sound quite right.

Do these various files have the same contents on both machines?
Generating a certificate twice (even with the same identifying info)
will result in different public and private keys, and therefore a
different certificate.  Every time you run "openssl req" to generate a
new certificate request, it generates a new public and private key pair
as well.

Now, if ca-cert.pem has the same contents (not just ID info, but the
public and private key as well) on both machines, *and* the private key
for that ca-cert.pem was the key that was used to sign the cert request
from both machines, then it should also work (assuming both machines
trust that particular ca-cert.pem file).  Because in that case, both
certs will chain to the single trusted ca-cert.pem file.

Also, if you copy the server.pem files across machines (and name them
something different), they can act as trusted root certificates.  Point
wpa_supplicant to the RADIUS server's version of server.pem, and point
the RADIUS server to wpa_supplicant's version of server.pem, and it
might work.

Although I should note: that will only work if you have a single EAP-TLS
client.  If you have to support more than one client, you'll have to do
a full CA (see the alternate sial.org link below).

> http://sial.org/howto/openssl/self-signed/

That looks like it'll work fine for HTTPS certs, but the steps there
have some issues if you're trying to create RADIUS certs.

> 1] Do we have to use FreeRadius itself? Cannt we use the hostapd as 
> RADIUS server itself?

You should be able to use hostapd, yes.  At least, I think.

> 2] Does this error makes us believe that we have to get the
> certificate from VeriSign or someone?

No, you don't -- I'm using a (private) CA with EAP-TLS, with nothing
from VeriSign, and it works OK.  Although I'm not using hostapd as the
RADIUS server, it shouldn't matter.  (And actually getting a cert from
VeriSign might mess up more stuff than it'll fix.)

> The paths given to the .pem and .prv files are the same at both the
> end i.e. AP and STA. The .pem and .prv are sitting the /etc folder
> itself.

Yes, but if the files themselves are different, that will cause issues.  :-)

> B] " you may also have to set the RADIUS server to accept the cert 
> you're using in wpa_supplicant."
> 
> The fiels and the contents are the same both ends, hence does it not 
> mean that the RADIUS should be able to accept the STA and
> authenticate it.?

It should be able to, yes.  When I said that, I was thinking about the
ability to reject certain certs that some RADIUS servers have.  For
instance, FreeRADIUS has the ability to reject a cert if its CN doesn't
match the client's user name.

> C] " 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 CSR that is explained on the website is the same as what you have
> suggested, right?

No, not really.  The cert that that page generates has a "basic
constraints" field that says it *can't* be a CA.  (That's because that
page is geared towards generating a web server cert.)

This page:

http://sial.org/howto/openssl/ca/

has a setup that might work.  (But note that this is a lot more
complicated than what you have now.  If you only have one client, and
you just use the other end's cert as the trusted root cert on both ends,
that might be enough to get it to work.)

> D] Isn't the certificate and key creation on both the machines 
> separately, using the same commands and files, one and the same?

Nope.  :-)  The identifying information in the certs is the same, but a
cert has more than just identifying information.  It also holds a public
key, whose bits depend on a private key.  Each certificate request that
gets generated creates a new private and public key-pair.

(The whole point of a cert is to bind a public key to some identifying
information.  Without the public key, it can't actually do that.  :-) )
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHLyaSS5vET1Wea5wRA4YsAJ9XmoKxDuHZDJFRnpMlfJg9xab0wQCaAwDy
YTUwS/voYZLgPrEdOS5GV8Q=
=DtXT
-----END PGP SIGNATURE-----