[Openswan Users] README.nss

[Michael H. Warfield]

Hey all!

A poster in another thread rang a notification bell in my head that I
was overdue to try and convert my classical X.509 cert setups over to
the newer NSS setups being promulgated by RedHat and Fedora.  So I had
some spare cycles on my hands this weekend and decided to revisit this
whole NSS debacle.  That whole mess just rubbed me the wrong way but I
have this OCD philosophy of NEVER breaking an existing working
configuration, or, at least, trying real damn hard not to, if I can
avoid it.  I had tried several times in the past to make this work and
never could.  I found articles on the net that said you couldn't import
private keys, which made no damn sense since Mozilla does that with the
pkcs12 .p12 files or client certs in FireFox wouldn't work (which I've
used for years).

So...  This time I finally found the right combination of blue smoke and
magic that worked!  I also came to the conclusion that either there was
a bug in Openswan (really unlikely - in this case) or README.nss was
sorely lacking in a few minor details (highly likely, IMNSHO).  I also
realized, with a slight shift in my conventions, I could script the
conversion process and, at the at the same time, create a set of config
files that would work either way, with an NSS enabled Openswan or one
without NSS.  This is cool!  This is the result...

First...  I found, during my latest effort following the instructions in
README.nss, things still didn't work but it wasn't complaining that it
couldn't find the host key (so much for the "can not import private key
theory").  No, the connection for "complex.wittsend.com" (a peer from
Romulus) was failing with "can not find complex.wittsend.com.crt in NSS
database".  Ooo...  Now that's interesting.  Romulus has a cert for
Complex but does not have a private key.  IT DOES NOT NEED THE BLOODY
PRIVATE KEY.  Based on my reading of README.nss, I was expecting
Openswan to pick that cert up from the file (ok - maybe a bad assumption
on my part - shame on me).  Apparently not and README.nss gives no clue
how to import certs into the NSS database if you do NOT have the private
key and use the pk12util to import it.  This is a real problem.  The way
that README is phrased, left me with the impression that I could just
leave certs in the old locations (it even says that for CA certs).  Not
true.  Not good.

I figured out that I needed to use the "certutil -A" command to add a
certificate to the NSS database.  Just had to struggle a bit with the
"nic name".  The default name that gets picked blows goats to put it
kindly.  It's the concatination of the DN and the ON from the X.509 cert
so Complex came out something like "complex.wittsend.com Thuamaturgy &
Speculums Technology".  FOR A NICNAME?  Yeah...  No.  Really?  Yeah...
No.  To be put in my configuration files instead of the certification
name?  Yeah...  Hell no.

Bottom line there is that every cert, that is not imported through
pk12util and a .p12 file (i.e. any cert for which you do not have a
corresponding key file), needs to be added using this command:

certutil -A -n ${NICNAME} -t u,u,u -i ${CERT} -d /etc/ipsec.d

Then the "rightcert=" (Remote cert by convention) in the config has to
be updated to match "NICNAME".  THAT's what's not clear in the
README.nss file.

Ok...  Then I thought, what if I changed things up in my non-NSS setup a
bit.  I've been using this convention (taken from my script - everything
relative to /etc/ipsec.d)...

# Old convention...
#       Public certs: certs/FQDN.crt
#       Private keys: private/FQDN.key
#       CA certs:     cacerts/NAME.crt
#       leftcert - Local Cert = "FQDN.crt"
#       rightcert - Peer Cert = "FQDN.crt"
#       RSA Secret - : RSA FQDN.key ""

With NSS the right/left cert is a nicname.  Without NSS the rightleft
certs are the file names in their respective directories.  What if that
was the same?  What if I used the FQDN as the "nic name" in the NSS
database AND as the file name for the certs and keys?  Then I just drop
the extensions on the file names and it's all congruent, NSS or
classical.  Reason for needing to do that is also since the name in
the .secrets file needs to be the same name as that in the default
leftcert config.

New convention becomes this:

# New convention...
#       Public certs: certs/FQDN
#       Private keys: private/FQDN
#       CA certs:     cacerts/NAME
#       NSS cert nic: FQDN
#       leftcert - Local Cert = "FQDN"
#       rightcert - Peer Cert = "FQDN"
#       RSA Secret - : RSA FQDN

That works for me and that's now scriptable.  Wrote the script, which
I've attached, and used it to update a dozen or so machines this
afternoon that can now operate with an NSS enabled version of Openswan
or a non-NSS enabled version of Openswan without changing the bloody
configs.  I'm now a happy camper and seriously starting to change my
view that NSS is a steaming pile of dung.

Nice advantage to me now is that I can run this script on running
working systems and convert the configurations and test it without
swapping out the Openswan modules.  If it doesn't work (and it has
worked, every time, for me so far - and I'm now done with all MY
production systems) the files can be easily reverted.  It was intended
to be relatively non-destructive.  If it works, then the NSS version of
Openswan can then be dropped in at any point in time in the future and
it won't know or care.  And you can change to a non-NSS version if you
want, and it won't know or care.  Only issue remaining for me (and is
also NOT addressed by README.nss either) is dealing with certs when they
expire and need to be updated.  :-X

Philosophical thoughts on README.nss, though.  As a cryptographer, I am
morally offending by some of the things in there.  It says to export the
CA keypair to a pkcs12 .p12 file and import them onto other machines.
Private keys should only exist on the machines to which they belong.
That's fundamental.  I can not possibly overstress that concept.  Using
pkcs12 requires including the private key (someone please correct me if
I'm wrong on this with pointers to the correct openssl syntax to do it).
(And yes, I am equally offending by sites offering client SSL or S/MIME
p12 certs which means they generate the private key for you.)  The idea
of having the private key of the CA on all the client machines is
insane!  The fact that there's no mention of importing peer certificates
into the database other than through .p12 files (which requires the
private key to be included) is equally crazy.  To me, this violates some
of the very principles of a whole PKI infrastructure.  Someone
compromises a single machine and they can extract the CA private key for
your entire VPN?  Really?  My CA is on an isolated machine that does not
even participate in that VPN.  I generate certs and sign them on that
machine and install them on the target machines.  Ideally, a client
should generate his own key pair and hand me the .csr certificate
request and I give his .crt cert back to him to install and to
distribute to other machines (sans private key).  README.nss does not
touch on this at all.  The way that file reads, you might as well be
using PSK.  Actually, PSK might even be more secure.

That file needs a good read a rewrite.  I may provide some patches to it
later on after I've thought about it.

IAC...  For anyone using or coming close to my particular conventions
for classically using X.509 certs and wanting to convert them to use the
Fedora/RedHat repo installs of Openswan, I've attached my script.  Do
NOT assume you can just run it.  Look at it and look at its assumptions
and make sure you comply with those assumptions.  Otherwise, don't run
it at all but use it as a guide on how you might do the same thing.
That's what I really intended this script as.  An educational guide for
how you can convert from classical openssl X.509 certs to an NSS
database.

shar and enjoy (even though it's not a shar file  :-P )

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openswan2nss.sh
Type: application/x-shellscript
Size: 4147 bytes
Desc: not available
Url : http://lists.openswan.org/pipermail/users/attachments/20110123/f785d6e7/attachment-0002.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
Url : http://lists.openswan.org/pipermail/users/attachments/20110123/f785d6e7/attachment-0003.bin