• entries
  • comments
  • views

About this blog

I'm doing stuff... see?

Entries in this blog


Happy to report that the Linksys WMP11 card works perfectly with FreeBSD (and, thus, the pfSense firewall). I did some additional tinkering with the box, and now have the following interfaces:WAN: My DSL connection.LAN: The "normal" home network; this is the network that my RADIUS-enabled WiFi connects to.WiFi: My new access point with the WMP11 card. Currently have it set up as open access, firewalled so that it is Internet only (no connections permitted to other interfaces, and no access to the firewall GUI). pfSense has a "captive portal" option that allows you to force a username/password sign-on via the web before the Internet can be accessed... I may futz around with something like that. Or whatever.DMZ: Normal DMZ interface. Have a laptop running Slackware here that I'm going to make into a web server.XLAN: My own naming convention, for "eXclusive LAN"... or in other words, a LAN with no outbound connections to the Internet or to other interfaces. Toying with the idea of setting up a wargame server or a spare router here and just opening it up for connections from the Internet (for people to play with). For now, there's not even a cable plugged into it... this was more an issue of "Hey, I have a spare ISA slot and a spare ISA network card. Woo."Hm. That's what everybody's home network looks like... right?


Today I went to an area hamfest and spent a couple hours wandering around with a friend of mine. Lots of fun stuff to look at, but I was a bit leary about making any big-ticket purchases. (Hamfest purchases are like a box of chocolates... etc....) Was unsuccessful in finding a power supply I needed, but I happened by a table that had all sorts of cheap WiFi gear. While I was tempted to grab one of everything, I settled for getting an old-ish looking Linksys wireless PCI card for a whopping $5. I didn't even check the model number or anything... I just figured that even if it turns out to be a dud, I'm only out a few bucks.Got it home and took a look at it. It appears to be a Linksys WMP11 (11 referring to 11 Mbit/sec, or 802.11b I am assuming). I did some web searching for it to see about getting that model card to run under a non-Windows OS. Most sites referenced a version number for compatibility, as the different versions of the card used different chipsets. This was puzzling, since I was unable to find a version number on the card anywhere. Finally, I found a listing of a number of wireless devices and their chipsets. This list told me that if there is *not* a version number on the card, then it is effectively "Version 1". The neat thing about this, is that the version 1 (or whatever it's called) of this particular card uses a chipset (Prism2) that is linux-friendly, while later versions use less cooperative chipsets.So... I am now going to plug this card into my firewall box and see if I can turn it into an access point.Because... you know... it would be cool. Never mind that I already have one in my house. This way I can have one for guests to use, that isn't attached to my LAN at all (and that I wouldn't have to generate certificates for everyone else to use). I am somewhat tempted to leave it open, but I'll have to see how that goes. At the very least, if I do end up tinkering with my ZyXEL wireless router and brick it, I would still be able to have a wireless network in the house.


Before the fresh info in my brain fades into the realm of "that was cool a while ago", I wanted to be sure I posted copies of all the working config files here for the RADIUS/WiFi setup. I will add some commentary where applicable, but this is basically just going to be a laundry list. (If anyone actually reads this and has any questions, I'll be happy to add more descriptiveness.)The Equipment:

  • ZyXEL P-330W Wireless Router (firmware v1.8)
  • Pentium III server: OpenBSD 4.2, FreeRADIUS 1.1.6, OpenSSL 0.9.7j
  • Laptop (WiFi client): Windows XP SP2
  • Laptop (WiFi client): Debian GNU/Linux 4.1 (etch), wpa_supplicant 0.5.5

So let's begin. The wireless router "Wireless Security Setup" page looks like this:pajkeaabj.jpgThe "password" field on the bottom is where the shared secret from the RADIUS server goes.Next up, the RADIUS server. First, the OpenSSL config file (/etc/ssl/openssl.cnf):

## OpenSSL example configuration file.# This is mostly being used for generation of certificate requests.#RANDFILE                = /dev/arandom####################################################################[ ca ]default_ca      = CA_default            # The default ca section[ CA_default ]dir            = ./masterCA              # top dirdatabase       = $dir/index.txt        # index file.new_certs_dir  = $dir/newcerts         # new certs dircertificate    = $dir/cacert.pem       # The CA certserial         = $dir/serial           # serial no fileprivate_key    = $dir/private/cakey.pem# CA private keyRANDFILE       = $dir/private/.rand    # random number filedefault_days   = 365                   # how long to certify fordefault_crl_days= 30                   # how long before next CRLdefault_md     = md5                   # md to usepolicy         = policy_anything       # default policyemail_in_dn    = no                    # Don't add the email into cert DNname_opt       = ca_default            # Subject name display optioncert_opt       = ca_default            # Certificate display optioncopy_extensions = none                 # Don't copy extensions from request# For the CA policy[ policy_anything ]countryName             = matchstateOrProvinceName     = matchorganizationName        = matchorganizationalUnitName  = optionalcommonName              = suppliedemailAddress            = optional[ req ]default_bits            = 1024default_keyfile         = privkey.pemdistinguished_name      = req_distinguished_nameattributes              = req_attributes[ req_distinguished_name ]countryName                     = Country Name (2 letter code)countryName_default             = UScountryName_min                 = 2countryName_max                 = 2stateOrProvinceName             = State or Province Name#stateOrProvinceName_default    = Some-StatestateOrProvinceName_default     = PennsylvanialocalityName                    = LocalitylocalityName_default            = Pittsburgh0.organizationName              = Organization Name ("Issued By")#0.organizationName_default     = Internet Widgits Pty Ltd0.organizationName_default      = Bit Bucket# we can do this but it is not needed normally :-)#1.organizationName             = Second Organization Name (eg, company)#1.organizationName_default     = CryptSoft Pty LtdorganizationalUnitName          = OU Name#organizationalUnitName_default =commonName                      = Common Name (Fully-qualified Hostname)commonName_max                  = 64emailAddress                    = Email AddressemailAddress_default            = dev@null.comemailAddress_max                = 64[ req_attributes ]challengePassword               = A challenge passwordchallengePassword_min           = 4challengePassword_max           = 20unstructuredName                = An optional company name[ x509v3_extensions ]nsCaRevocationUrl               = http://www.cryptsoft.com/ca-crl.pemnsComment                       = "This is a comment"# under ASN.1, the 0 bit would be encoded as 80nsCertType                      = 0x40#nsBaseUrl#nsRevocationUrl#nsRenewalUrl#nsCaPolicyUrl#nsSslServerName#nsCertSequence#nsCertExt#nsDataType

Most of the significant stuff there is near the top, from the [ ca ] sections through the [ policy_anything ] sections. Note that if you already have a valid CA somewhere, you can just use that instead.OpenSSL also needs a file with some tweaks for any certificates to be created for Windows XP clients. Here is the contents of this file (/etc/ssl/xpextensions):

[ xpclient_ext]extendedKeyUsage =[ xpserver_ext ]extendedKeyUsage =

I don't know what any of that means yet, either.Here are the commands needed to generate client certificates:

# create signing request for clientopenssl req -new -keyout client_key.pem -out client_req.pem -days 730 -config ./openssl.cnf# sign the request (cert can be used with *nix)openssl ca -config ./openssl.cnf -policy policy_anything -out [certificate-name].pem -extensions xpclient_ext -extfile ./xpextensions -infiles ./client_req.pem# convert to PKCS12 (for WinXP)openssl pkcs12 -export -in [certificate-name].pem -inkey client_key.pem -out [certificate-name].p12 -clcerts

Next up, the FreeRADIUS stuff. The FreeRADIUS config file (/etc/raddb/raduisd.conf) points to a separate file for EAP configuration. Here is the portion of /etc/raddb/eap.conf that I had to modify:

tls {						private_key_password = "XXXXXXXX" [Not gonna share *that* with the world!]						private_key_file = ${raddbdir}/certs/server_keycert.pem						certificate_file = ${raddbdir}/certs/server_keycert.pem						CA_file = ${raddbdir}/certs/cacert.pem						dh_file = ${raddbdir}/certs/dh						random_file = ${raddbdir}/certs/random				}

The server_keycert.pem file is the file that contains both the certificate and key for the FreeRADIUS server. The cacert.pem file is the signing certificate from the CA I set up.Also need to modify the client configuration file (/etc/raddb/clients.conf), to specify which machines are allowed to use this server for authentication. Note that in the RADIUS world, "client" means "thing which asks the RADIUS server if someone is allowed in" -- in other words, our wireless router in this case. The term "supplicant" is used to represent the device (e.g. laptop) that is requesting access. Here is clients.conf:

client {		secret = XXXXXXXX [Again, secret stuff here.]		shortname = commo}client {		secret = XXXXXXXX		shortname = nato} is the IP address of the wireless router. Should go without saying that files with passwords in them should be readable only by root.Something else I learned, which may or may not be significant. FreeRADIUS will try to get an authentication match however it can using its config files. There is a file named users (/etc/raddb/users), which allows for basic username/password authentication. I had some users entered into this file for testing purposes (i.e. making sure the RADIUS server was working properly); what I found was that if the EAP-TLS authentication could not find a valid certificate on the laptop, it would revert to using the username/password combo found in this file. Removing the file generates an error and prevents FreeRADIUS from starting properly... so I just created an empty file named users.conf and all is well once again. This is another file to make sure that only root can view/edit. If someone were to sneak a username/password in there, they could bypass whatever other authentication you were using RADIUS for.Another note about FreeRADIUS. Apparently, the version of FreeRADIUS that comes as a Debian package does *not* include support for EAP-TLS authentication. I'm not 100% sure why, though I think it has something to do with a conflict between OpenSSL and the Debian Free Software Guidelines. If you are intending to use Debian GNU/Linux to run FreeRADIUS, you will need to either tweak the package or install from source. An Internet search for "Debian FreeRADIUS EAP-TLS" found me a page that provides a way to patch the default package; but I didn't try it out so I can't verify. (I had enough trouble with OpenBSD.) I'm sure there are numerous guides out there, given Debian's huge user-base.For the Windows XP laptops, you can use the MMC "Certificates" snap-in to add the certificate you create. I added the client ("supplicant") certificate I generated with OpenSSL, as well as the CA certificate from my OpenBSD server as a Trusted Root CA (so that the client certificate would have a valid path... I don't know if that makes a difference or not, but it doesn't hurt). There are various third-party applications you can use for WPA/EAP authentication, but I found that the built-in "Wireless Connection" network connection in XP worked fine. During the connection, I was prompted to select a certificate to use for authentication. I did not have to do any other configuration in XP.The linux laptop was more challenging. I had the madwifi drivers set to use the wpa_supplicant program already (for WPA-PSK authentication that I had been using), so it was just a matter of adjusting the wpa_supplicant.conf file to use EAP-TLS authentication instead. I have an entry or two about this process, so I will not go into great detail here. Instead, here is the syntax that allows it to work:

ctrl_interface=/var/run/wpa_supplicantnetwork={		ssid="l33t"		key_mgmt=WPA-EAP#	   proto=WPA#	   pairwise=TKIP#	   group=TKIP		eap=TLS		identity="/etc/ssl/certs/cert_19delta.pem"		ca_cert="/etc/ssl/certs/cacert.pem"		client_cert="/etc/ssl/certs/cert_19delta.pem"		private_key="/etc/ssl/certs/cert_19delta_key.pem"		private_key_passwd="XXXXXXXX"}

Items commented out are defaults; I just had them in there "just in case".There we go. Submitted for your approval.I have discovered a forum dedicated to the ZyXEL hardware, and found that this particular router's RADIUS implementation does not seem to be complete. While the details elude me, right now it is enough for me to know that it is working as I expected it to, and that my neighbors would have to be pretty slick in order to sneak onto my wireless network.Either that, or just read this blog.But another neighbor has an open AP onto his cable connection... so someone looking for an easy target could pass me by. :)


Got it.I poked around the mailing list for wpa_supplicant for a bit... and while I didn't discover a specific fix for my problem, I did find that you can run wpa_supplicant from the command line with the "-dd" option for extremely verbose output. Dumping the output to a file, I found the following section that sounded kind of familiar to what I had seen with the wpa_cli app:

CTRL-EVENT-EAP-STARTED EAP authentication startedEAP: EAP-Request Identity data - hexdump_ascii(len=0):EAP: using real identity - hexdump_ascii(len=0): [NULL]EAP: buildIdentity: identity configuration was not availableCTRL-REQ-IDENTITY-0:Identity needed for SSID l33tEAP: EAP entering state SEND_RESPONSEEAP: EAP entering state IDLE

There was more stuff around it, but that basically repeated itself a couple times each minute. On a whim, I added the following line to my wpa_supplicant.conf file:


One reboot later, everything was working like clockwork. The documentation for wpa_supplicant.conf is pretty spartan regarding the "identity" parameter, something along the lines of "an identity to be used for authentication". I had probably read it a number of times, but it never stood out as significant.Either way, all seems to be well at this point. Later I'll post copies of the various apps and config files, in the event that anyone wants to reproduce my work for their own environment. (Assuming anyone else but me is actually, you know, reading this thing....)


Normally, I think those userbars in signatures can be a bit obnoxious. I really don't care who is an American Idol Watcher, or who is a Pot Smoker, or whatever. However, I tinkered a bit, and came up with one that I think I can tolerate:


Basically a vanity job, also showing off my new domain: slicktech.net (the first one I've ever had all to myself).Woo.


Ironically enough -- since the article I was referencing for my FreeRADIUS / EAP-TLS / WiFi setup was written in Linux Journal magazine -- I've had some difficulty getting my linux laptop connected to the AP. With WPA-PSK (i.e. WPA with a password), it worked fine with the madwifi drivers and the wpa_supplicant program. However, trying to tweak wpa_supplicant to work with the EAP-TLS settings has been... challenging... frustrating... annoying. The magic seems to happen in the wpa_supplicant.conf file, and I'm struggling to figure out where it's not right.

The cool thing, that I just discovered, is that there is an interactive interface to the wpa_supplicant app called wpa_cli. Running this program allows you to see the responses coming from the AP and issue commands. Using this interface, I was able to see the identity request, and found this magic command was what I needed:

identity l33t /etc/ssl/certs/cert_19delta.pem

That is, set my identity for the AP named 'l33t' to the specified certificate. A few seconds later, I received an "identity accepted" message. I then had to run dhclient for my DHCP address, and got it.

So... I am now connected (and doing this blog entry with that very laptop), but not automatically. This tells me that my certificates and such can do what they need to, but something somewhere is not quite jiving.

More to come when I figure it all out. I will post full config files for each portion of the process when everything is working as it should. (If for no other reason than so I don't forget when I go to do this again sometime.)

So stay tuned.


Happy to say that I finally got all the parts of the WiFi RADIUS authentication working on my home network this evening, a little after midnight. As of this writing, my two Windows XP laptops now connect automatically... now I just have to figure out how to set it up on my Debian laptop. (I don't have any of the fancy-schmancy GUI utilities on it, so I tweak the network settings by hand in the config files). Also have to figure out how to add a certificate to the laptop. But enough learning for today... once everything is taken care of, I'll post a step-by-step summary of what has to happen in order to get it all working right, with client info for both XP and linux.Final "D'oh!" moment was spending some time staring at the log files for both my AP and RADIUS server when I was attempting to authenticate. The AP indicated that it was forwarding EAP-TLS requests to the server, but the server didn't seem to be doing anything. This was highly frustrating to me; I was preparing to blame it on a cheap foreign-made router, when I discovered something.I had put the wrong IP address into the "RADIUS Server" field.Heh.Turns out that using the *CORRECT* IP address for the RADIUS server makes all the difference. You may want to write that down somewhere so you don't forget it. :)



Okay, I have finally gotten to the point where I'm using OpenSSL to create certificates. As much as I hate to just copy and paste stuff into a command line and press return, the tutorial I've been following has done a pretty good job of explaining along the way. At some point I am going to go back through the man page and see what the various options that I am invoking actually do... but for now, I did manage to get a couple client certificates set up, and one of them added itself to a Windows XP box successfully. Next step is to add the FreeRADIUS server cert and tweak the config files to accept my client certs.Last step will be to tell my WiFi AP to look at my FreeRADIUS server. I had tried that before (using a simple username/password setup) with a different FreeRADIUS server and it didn't work at all. I'm hoping that it will work better now that it's far more complex. :)Final step for me will be to go back and automate the certificate generating process, so I don't always have to bring up the tutorial and copy/paste the info in when I need a new certificate. Then maybe set it up as a web app.Or something.[Edit: Hm... somehow, this was saved as a Draft and never got published until now. Better late than never?]


Apparently the default openssl.cnf that comes with OpenBSD has been "streamlined" so that some stuff required by the how-to guide I'm following is missing. I'm not l33t enough to work around it, so I found that copy/pasting chunks from the OpenSSL source download of the same version seems to work OK. Have to pay attention to the error messages and do a little creative re-typing... but it seems to have gotten me to the point where I need to be.

So far.

Security is good, and I suppose you tend to learn more when stuff breaks and you have to fix it as you go, but since this is an almost totally new realm for me anyway, it feels like every step leaves me banging my head against hard, sharp pointy stuff.



K.I.S.D... for "Keep It Simple, Dumbass"I don't know much about RADIUS as a protocol, and I don't know much about the FreeRADIUS app. I have used Microsoft's bizarro-RADIUS implementation called "Internet Authentication Service"... through which I managed to set up what I think is EAP-TLS on a domain, used for wireless and VPN authentication. I more or less clickey-clicked my way through, and couldn't re-explain to anyone else at this point how I managed to do it. (I hope it doesn't break!)Anyway, as with most things in the *nix world, FreeRADIUS uses various configuration files to keep track of the program options. I found a web-based GUI utility, called Dialup Admin, that is apparently the "official" GUI for FreeRADIUS (never mind that it hasn't been updated in the last few years). I thought it would help ease my transition into the wonderful world of AAA/RADIUS if I installed this utility. You know, just until I figured out the configuration files.So... I had to enable httpd on OpenBSD. This is basically a tweaked version of Apache that, among other things, runs in a chroot setting. The devs of Dialup Admin have the program configured in such a way that is designed to have its main directory "somewhere" in the filesystem, and use soft links to get between /var/www and wherever you put the rest. Works fine in theory, except that chroot breaks the hell out of that setup. Spent some time trying to move files back and forth and change the references... then just went ahead and dropped the whole thing into the /var/www directory (which, you know, includes the config files with passwords and stuff).After several hours of frustration, I finally just scrapped the whole Dialup Admin program. Time spent trying to get all the files to point to each other while not spitting config files out into the browser was time I *wasn't* learning about RADIUS.Tried to add complexity to the overall setup, cost me some time without getting me any closer to a working environment.Next on the list... FreeRADIUS has support for using MySQL to keep track of the data and configuration. Not being one to just use the default setup originally, I proceeded to install MySQL on the OpenBSD box, then set up the necessary configuration for FreeRADIUS. Now... MySQL runs from the command line by default, and it can be a bit goofy to use if you're like me and haven't done command line MySQL syntax for the last few years. I was able to add a new user and grant access to the database, but I hate having to type SQL queries out by hand to see what all is going on, or to have to insert new data (then I have to read through the shema and data dictionary, and wonder what each field means). phpMyAdmin is (yet again) a web-based GUI for MySQL that basically removes the command-line mystique and actually lets you get into your data.So... since I already had httpd running, I decided I'd set up phpMyAdmin and use that for MySQL administration. Initial setup seemed to go okay, right up until I got to the main login screen. I tried logging in as both root and the freeradius user, and in each case received an odd error about the socket not being configured correctly. Spent another couple hours clickey-clicking about Teh Interweb, looking for some possible solutions (again, OpenBSD's uber-secure setup causes some different stuff to happen in different places). Tried changing the phpMyAdmin configuration to hard-code the user/pass into the config file, but that didn't work out either. Decided to abandon phpMyAdmin, again having spent some time trying to solve problems not directly related to the task at hand.Now it turns out that the config files for FreeRADIUS aren't really that difficult to understand... if you go about them the right way. The default/sample files that come with the program are chock-full of all sorts of special conditions and various options that might make sense if I were rolling my own ISP or telco, but not so much for a basic setup like I'm trying. My firewall box (running pfSense) has a working FreeRADIUS implementation on it, which I use for VPN authentication into my home LAN. I took a quick look at the config files for that install, and they are much easier to understand.Thus, I was able to get the OpenBSD FreeRADIUS config files looking the way I needed them to.I was now at the point where I was ready to use the radtest app to verify that FreeRADIUS would return an approval if I provided a valid user/pass combo. Of course, everything I tried (even double and triple checking the spelling, IP addresses, shared secrets) was failing. So... spent some more time poking around for yet another answer.Turns out that if MySQL is configured, then FreeRADIUS pays no attention to the config files. I hadn't eliminated the database yet, and MySQL was still running on the server. Thus, it was looking at an empty database for config info, instead of my carefully crafted text files. Shut down MySQL, removed all references to it in FreeRADIUS, and BAM -- got the approval note straight away from radtest.So basically, I spent several hours fiddling with a modified web server, various GUIs that didn't work right, and some MySQL tomfoolery in order to try and make my life easier... instead of just spending a bit of time *looking* at what I needed which, as it turned out, wasn't as complex as I thought it was.That's what being lazy got me. Lots and lots of extra work with no additional payoff. :)Then I spent a while writing up this blog entry, instead of actually working on the setup some more. Hm... I'll have to blog about that, too.When I get the chance.


I'm using OpenBSD (v 4.2) to run a RADIUS server, which I intend to use for the WLAN. I've got FreeRADIUS (v 1.1.6) installed and it seems to be working properly, at least as far as simple username/password authentication. OpenBSD has proven to be a bit of a challenge for this purpose, in some interesting ways. The most recent challenge has been using OpenSSL (v 0.9.7j)... I have only tacit knowledge of the whole "certificate" process, and futzing with SSL on the command line has invoked some serious head-scratching and Google-jutsu to say the least.Most frustrating thing (so far) has been mention of a magical shell script named CA.sh, that streamlines the process of setting up a certification authority for the certs for use with RADIUS. Apparently the default OpenSSL install that comes with OpenBSD has some stuff stripped out. And, wouldn't you know it, this magical CA.sh script was one of the things they removed.One guy suggested just re-downloading the OpenSSL source and grabbing the file from there, which I did. I am posting the contents of the file here, in the bizarre chance that someone doing the same thing I did should stumble across this site first, or not think to check the source code on the openssl.org website. So here it is, CA.sh in its entirety:

#!/bin/sh## CA - wrapper around ca to make it easier to use ... basically ca requires#      some setup stuff to be done before you can use it and this makes#      things easier between now and when Eric is convinced to fix it :-)## CA -newca ... will setup the right stuff# CA -newreq ... will generate a certificate request # CA -sign ... will sign the generated request and output ## At the end of that grab newreq.pem and newcert.pem (one has the key # and the other the certificate) and cat them together and that is what# you want/need ... I'll make even this a little cleaner later.### 12-Jan-96 tjh    Added more things ... including CA -signcert which#                  converts a certificate to a request and then signs it.# 10-Jan-96 eay    Fixed a few more bugs and added the SSLEAY_CONFIG#		   environment variable so this can be driven from#		   a script.# 25-Jul-96 eay    Cleaned up filenames some more.# 11-Jun-96 eay    Fixed a few filename missmatches.# 03-May-96 eay    Modified to use 'ssleay cmd' instead of 'cmd'.# 18-Apr-96 tjh    Original hacking## Tim Hudson# tjh@cryptsoft.com## default openssl.cnf file has setup as per the following# demoCA ... where everything is storedif [ -z "$OPENSSL" ]; then OPENSSL=openssl; fiDAYS="-days 365"REQ="$OPENSSL req $SSLEAY_CONFIG"CA="$OPENSSL ca $SSLEAY_CONFIG"VERIFY="$OPENSSL verify"X509="$OPENSSL x509"CATOP=./demoCACAKEY=./cakey.pemCACERT=./cacert.pemfor idocase $i in-\?|-h|-help)    echo "usage: CA -newcert|-newreq|-newca|-sign|-verify" >&2    exit 0    ;;-newcert)     # create a certificate    $REQ -new -x509 -keyout newkey.pem -out newcert.pem $DAYS    RET=$?    echo "Certificate is in newcert.pem, private key is in newkey.pem"    ;;-newreq)     # create a certificate request    $REQ -new -keyout newkey.pem -out newreq.pem $DAYS    RET=$?    echo "Request is in newreq.pem, private key is in newkey.pem"    ;;-newca)         # if explicitly asked for or it doesn't exist then setup the directory    # structure that Eric likes to manage things     NEW="1"    if [ "$NEW" -o ! -f ${CATOP}/serial ]; then	# create the directory hierarchy	mkdir ${CATOP} 	mkdir ${CATOP}/certs 	mkdir ${CATOP}/crl 	mkdir ${CATOP}/newcerts	mkdir ${CATOP}/private	echo "01" > ${CATOP}/serial	touch ${CATOP}/index.txt    fi    if [ ! -f ${CATOP}/private/$CAKEY ]; then	echo "CA certificate filename (or enter to create)"	read FILE	# ask user for existing CA certificate	if [ "$FILE" ]; then	    cp $FILE ${CATOP}/private/$CAKEY	    RET=$?	else	    echo "Making CA certificate ..."	    $REQ -new -x509 -keyout ${CATOP}/private/$CAKEY \			   -out ${CATOP}/$CACERT $DAYS	    RET=$?	fi    fi    ;;-xsign)    $CA -policy policy_anything -infiles newreq.pem     RET=$?    ;;-sign|-signreq)     $CA -policy policy_anything -out newcert.pem -infiles newreq.pem    RET=$?    cat newcert.pem    echo "Signed certificate is in newcert.pem"    ;;-signcert)     echo "Cert passphrase will be requested twice - bug?"    $X509 -x509toreq -in newreq.pem -signkey newreq.pem -out tmp.pem    $CA -policy policy_anything -out newcert.pem -infiles tmp.pem    cat newcert.pem    echo "Signed certificate is in newcert.pem"    ;;-verify)     shift    if [ -z "$1" ]; then	    $VERIFY -CAfile $CATOP/$CACERT newcert.pem	    RET=$?    else	for j	do	    $VERIFY -CAfile $CATOP/$CACERT $j	    if [ $? != 0 ]; then		    RET=$?	    fi	done    fi    exit 0    ;;*)    echo "Unknown arg $i";    exit 1    ;;esacdoneexit $RET

Some other sites suggest a program called CA.pl, which is obtainable in the same way (also being absent from OpenBSD). Looks to be the same thing, just written in Perl instead of a normal shell script (for those of you who like gibberish):

#!/usr/bin/perl## CA - wrapper around ca to make it easier to use ... basically ca requires#      some setup stuff to be done before you can use it and this makes#      things easier between now and when Eric is convinced to fix it :-)## CA -newca ... will setup the right stuff# CA -newreq[-nodes] ... will generate a certificate request # CA -sign ... will sign the generated request and output ## At the end of that grab newreq.pem and newcert.pem (one has the key # and the other the certificate) and cat them together and that is what# you want/need ... I'll make even this a little cleaner later.### 12-Jan-96 tjh    Added more things ... including CA -signcert which#                  converts a certificate to a request and then signs it.# 10-Jan-96 eay    Fixed a few more bugs and added the SSLEAY_CONFIG#		   environment variable so this can be driven from#		   a script.# 25-Jul-96 eay    Cleaned up filenames some more.# 11-Jun-96 eay    Fixed a few filename missmatches.# 03-May-96 eay    Modified to use 'ssleay cmd' instead of 'cmd'.# 18-Apr-96 tjh    Original hacking## Tim Hudson# tjh@cryptsoft.com## 27-Apr-98 snh    Translation into perl, fix existing CA bug.### Steve Henson# shenson@bigfoot.com# default openssl.cnf file has setup as per the following# demoCA ... where everything is storedmy $openssl;if(defined $ENV{OPENSSL}) {	$openssl = $ENV{OPENSSL};} else {	$openssl = "openssl";	$ENV{OPENSSL} = $openssl;}$SSLEAY_CONFIG=$ENV{"SSLEAY_CONFIG"};$DAYS="-days 365";$REQ="$openssl req $SSLEAY_CONFIG";$CA="$openssl ca $SSLEAY_CONFIG";$VERIFY="$openssl verify";$X509="$openssl x509";$PKCS12="$openssl pkcs12";$CATOP="./demoCA";$CAKEY="cakey.pem";$CACERT="cacert.pem";$DIRMODE = 0777;$RET = 0;foreach (@ARGV) {	if ( /^(-\?|-h|-help)$/ ) {	    print STDERR "usage: CA -newcert|-newreq|-newreq-nodes|-newca|-sign|-verify\n";	    exit 0;	} elsif (/^-newcert$/) {	    # create a certificate	    system ("$REQ -new -x509 -keyout newkey.pem -out newcert.pem $DAYS");	    $RET=$?;	    print "Certificate is in newcert.pem, private key is in newkey.pem\n"	} elsif (/^-newreq$/) {	    # create a certificate request	    system ("$REQ -new -keyout newkey.pem -out newreq.pem $DAYS");	    $RET=$?;	    print "Request is in newreq.pem, private key is in newkey.pem\n";	} elsif (/^-newreq-nodes$/) {	    # create a certificate request	    system ("$REQ -new -nodes -keyout newkey.pem -out newreq.pem $DAYS");	    $RET=$?;	    print "Request is in newreq.pem, private key is in newkey.pem\n";	} elsif (/^-newca$/) {		# if explicitly asked for or it doesn't exist then setup the		# directory structure that Eric likes to manage things 	    $NEW="1";	    if ( "$NEW" || ! -f "${CATOP}/serial" ) {		# create the directory hierarchy		mkdir $CATOP, $DIRMODE;		mkdir "${CATOP}/certs", $DIRMODE;		mkdir "${CATOP}/crl", $DIRMODE ;		mkdir "${CATOP}/newcerts", $DIRMODE;		mkdir "${CATOP}/private", $DIRMODE;		open OUT, ">${CATOP}/index.txt";		close OUT;	    }	    if ( ! -f "${CATOP}/private/$CAKEY" ) {		print "CA certificate filename (or enter to create)\n";		$FILE = <STDIN>;		chop $FILE;		# ask user for existing CA certificate		if ($FILE) {		    cp_pem($FILE,"${CATOP}/private/$CAKEY", "PRIVATE");		    cp_pem($FILE,"${CATOP}/$CACERT", "CERTIFICATE");		    $RET=$?;		} else {		    print "Making CA certificate ...\n";		    system ("$REQ -new -x509 -keyout " .			"${CATOP}/private/$CAKEY -out ${CATOP}/$CACERT $DAYS");		    $RET=$?;		}	    }	    if (! -f "${CATOP}/serial" ) {		system ("$X509 -in ${CATOP}/$CACERT -noout "			. "-next_serial -out ${CATOP}/serial");	    }	} elsif (/^-pkcs12$/) {	    my $cname = $ARGV[1];	    $cname = "My Certificate" unless defined $cname;	    system ("$PKCS12 -in newcert.pem -inkey newkey.pem " .			"-certfile ${CATOP}/$CACERT -out newcert.p12 " .			"-export -name \"$cname\"");	    $RET=$?;	    print "PKCS #12 file is in newcert.p12\n";	    exit $RET;	} elsif (/^-xsign$/) {	    system ("$CA -policy policy_anything -infiles newreq.pem");	    $RET=$?;	} elsif (/^(-sign|-signreq)$/) {	    system ("$CA -policy policy_anything -out newcert.pem " .							"-infiles newreq.pem");	    $RET=$?;	    print "Signed certificate is in newcert.pem\n";	} elsif (/^(-signCA)$/) {	    system ("$CA -policy policy_anything -out newcert.pem " .					"-extensions v3_ca -infiles newreq.pem");	    $RET=$?;	    print "Signed CA certificate is in newcert.pem\n";	} elsif (/^-signcert$/) {	    system ("$X509 -x509toreq -in newreq.pem -signkey newreq.pem " .								"-out tmp.pem");	    system ("$CA -policy policy_anything -out newcert.pem " .							"-infiles tmp.pem");	    $RET = $?;	    print "Signed certificate is in newcert.pem\n";	} elsif (/^-verify$/) {	    if (shift) {		foreach $j (@ARGV) {		    system ("$VERIFY -CAfile $CATOP/$CACERT $j");		    $RET=$? if ($? != 0);		}		exit $RET;	    } else {		    system ("$VERIFY -CAfile $CATOP/$CACERT newcert.pem");		    $RET=$?;	    	    exit 0;	    }	} else {	    print STDERR "Unknown arg $_\n";	    print STDERR "usage: CA -newcert|-newreq|-newreq-nodes|-newca|-sign|-verify\n";	    exit 1;	}}exit $RET;sub cp_pem {my ($infile, $outfile, $bound) = @_;open IN, $infile;open OUT, ">$outfile";my $flag = 0;while (<IN>) {	$flag = 1 if (/^-----BEGIN.*$bound/) ;	print OUT $_ if ($flag);	if (/^-----END.*$bound/) {		close IN;		close OUT;		return;	}}}

Here's hoping this will be useful to someone.



Just wanted to set up an area where I can put some info on various "projects" I'm either working on, or have ideas for. Here's the short list at the moment:- My home wireless LAN connection currently uses WPA-PSK. I want to set it up so that it uses RADIUS authentication. So far, I've got a more or less working install of FreeRADIUS (actually, two), and am working on tweaking OpenSSL for the certificate stuff (I want to use EAP-TLS, none of this username/password stuff). Links:

- A couple years ago, I wrote an article for 2600 called "Filesharing using TinyURL.com". In the article, I described a way to convert a file to a text string of bytes, then upload that string to tinyurl.com and get a short link to that string. As a part of this article, I wrote two programs -- "implant" and "extract" -- to automate the process. I began working on an enhanced version of these programs to use a pastebin-type site (pastebin.ca) to allow for bigger files, with options like multithreading and variable file chunk sizes. I kind of stopped working on it, but I've got some new ideas for stuff to implement, and I think it would be cool to keep my Ruby practice up, as well as potentially develop something useful for sneaking files around to different places.No promises to how often this page will get updated, but it's a bit easier than trying to save things in various text files and carrying them with me from computer to computer (I tend to use several different computers in the course of a day).