Search the Community

Showing results for tags 'RADIUS Project'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • General
    • General.Rules, Guidelines and Announcements
    • Nubie HQ
    • General Hacking
    • Old Skool Phreaking
    • LinkZ
    • Hacker Media
    • Hacker Meetings
    • Programming/Code
    • HAM Radio/Hardware Hacking
    • Retail Hacking
    • Urban Exploration And Social Engineering
    • *NIX
    • Graphic Designs
  • BinRev members section
    • Assorted Projects
  • Off-Topic
    • General Chat
    • Scratchytcarrier's Joke-A-Thon

Calendars

  • Community Calendar

Blogs

  • StankDawg: Howling@the.moon
  • Brokennode
  • RedAnthrax the BLOG!!!
  • CETX_var_log
  • The Hillbilly Hacker
  • Exit Status One
  • Bit Bucket
  • 1337_snic's Blog
  • Kotrin's Blog
  • LibbsSecurity E|Hacker Network Security Blog
  • R4p1d's Blog
  • Ohm's Blog
  • Letting the smoke out
  • 1337_snic's Blog
  • 1337_snic's Blog
  • jeremy_.html
  • tekio's blog
  • lattera's Blog
  • The Microwave Rider

Categories

  • Audio
    • Internet Radio shows
    • Miscellaneous
  • Zines
    • Phrack
    • BR Magazine
    • PoC||GTFO
  • Video
    • HackTV

Found 8 results

  1. 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.7jLaptop (WiFi client): Windows XP SP2Laptop (WiFi client): Debian GNU/Linux 4.1 (etch), wpa_supplicant 0.5.5So let's begin. The wireless router "Wireless Security Setup" page looks like this:The "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#nsDataTypeMost 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 = 1.3.6.1.5.5.7.3.2[ xpserver_ext ]extendedKeyUsage = 1.3.6.1.5.5.7.3.1I 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 -clcertsNext 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 10.0.0.2 { secret = XXXXXXXX [Again, secret stuff here.] shortname = commo}client 10.0.0.57 { secret = XXXXXXXX shortname = nato}10.0.0.2 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.
  2. 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 IDLEThere 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: identity="/etc/ssl/certs/cert_19delta.pem"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....)
  3. 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.pemThat 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.
  4. 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.
  5. 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?]
  6. 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.
  7. 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.
  8. 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 $RETSome 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.