wpa_supplicant using EAP-TTLS problem

[Bryan Kadzban]

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

??? wrote:
> I found a page that describe how to create CA
> http://dsd.lbl.gov/~boverhof/openssl_certs.html

That looks a bit more complicated than what should be required, but
it'll probably work well enough.

> If I following his guide,
> and create 9 files:
> ca.pem, client.key, client.pem, client.req, file.srl,
> privkey.pem, server.key, server.pem, server.req
> 
> Which files should I put into RADIUS SERVER's raddb directory?

The server will require ca.pem, server.key, and server.pem.  You can
probably combine the second and third files, if you want: "cat
server.pem server.key >server-combined.pem", then use the full path to
server-combined.pem for *both* the certificate_file and private_key_file
options.

> which files shoud I put into host terminal's /etc/certs directory?

It will *probably* only require ca.pem.  However, wpa_supplicant will
require both client.key and client.pem somewhere (preferably some
directory that only root can read).  You can also combine these files if
you want to (just like with the server* files).

> at RADIUS SERVER,
> setup in eap.conf,
> private_key_file = privkey.pem

Actually, privkey.pem is for the CA only.  It should only be used when
you create new certificates (by signing requests).  Use server.key here
instead.

> certificate_file = server.pem

That's fine.

> CA_file = ca.pem

That should be fine too.

> at host terminal,
> put client.pem into /etc/certs/,
> and in wpa_supplicant.conf,
> set ca_cert=/etc/certs/client.pem

That won't work.  You'll need to set ca_cert to ca.pem, client_cert to
the full path to client.pem, and private_key to the full path to
client.key.  The last two files don't need to be in /etc/certs -- and
actually the first one doesn't either, but it won't cause any grief if
you do.

And keep privkey.pem VERY SAFE.  :-)

Responding to a few of the questions in your earlier message:

> Bag Attributes
>     localKeyID: 0C BA ED 0A 7B E9 67 CD E7 0A 08 39 DB 9D 99 34 0A C6
2B A4
> subject=/C=CA/ST=Province/L=Some City/O=Organization/OU=localhost/CN=Root
> certificate/emailAddress=root at example.com
> issuer=/C=CA/ST=Province/L=Some
> City/O=Organization/OU=localhost/CN=Client
> certificate/emailAddress=client at example.com

That's basically just the text interpretation of the identifying
information that's in the certificate.  If you delete those lines (up
until the BEGIN CERTIFICATE line), it won't affect the operation of the
cert; when OpenSSL loads in a cert, it ignores everything up until the
BEGIN CERTIFICATE line, then reads in the "raw" Base64-encoded data
until the END CERTIFICATE line.

If you want to reproduce the interpreted version of the cert, you can do
an "openssl x509 -in blah.pem -text -noout" -- the "-text -noout"
arguments prevent openssl from writing out any information to a file,
and tell it to print the text-form of the cert instead.

> -----END CERTIFICATE-----
> Bag Attributes
>     localKeyID: 0C BA ED 0A 7B E9 67 CD E7 0A 08 39 DB 9D 99 34 0A C6
2B A4
> Key Attributes: <No Attributes>

This looks like similar data for the private key.

(The rest of this earlier message won't be needed if you go with the CA
setup from that web page.)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHOQRaS5vET1Wea5wRAyyeAJ44HQFVxMTP+j8VWFU0OLgPITnf2wCeKzgD
QSPk+n3bvPJ0CeqokiEYAek=
=iMMy
-----END PGP SIGNATURE-----