Has anyone managed to configure an openswan tunnel under Fedora 13? The instructions in /usr/share/doc/openswan-doc-2.6.29 may have been correct once upon a time, but are simply wrong now.
Someone has judged that simple exchange of RSA public/private keys provides insufficient security, so that actual access to those keys is further restricted by something called "NSS support", whatever that is. Unfortunately, they neglected to tell anyone how to penetrate this extra veil of protection, as far as I have found, thus rendering a valuable security capability unusable by the good guys (me).
Can anyone point me to lucid and complete documentation of how to use the "new openswan" system? After groping through random googleisms, I found a way to create the needed RSA keys. Instead of the documented ipsec newhostkey --output /etc/ipsec.secrets one must first create an NSS password, which goes God-knows-where: certutil -N -d /etc/ipsec.d and then ipsec newhostkey --configdir /etc/ipsec.d \ --output /etc/ipsec.d/ipsec.secrets --password <thepasswd> to create the ipsec.secrets file, then move it up a level mv /etc/ipsec.d/ipsec.secrets /etc/ipsec.secrets
Then you can display the public key in the usual way ipsec showhostkey --left and use it to construct /etc/ipsec.d/net2net.conf based on the example in <doc>/openswan-doc-2.6.29/config.html.
After doing this on the local and remote gateway machines, so they know how to communicate and recognize each other, the tunnel ought to work. But it doesn't.
When I try to start the tunnel there's a mysterious error ipsec auto --up net2net ... 003 "net2net" #1: Can't find the private key from the NSS CERT (err -12285) ... and the negotiation fails.
Can anyone give a clue how to access this very well hidden private key? Google can't.
On Sat, 30 Oct 2010 13:08:38 -0400 David A. De Graaf wrote:
Can anyone give a clue how to access this very well hidden private key? Google can't.
A substitute for documentation can sometime be found by running the program under strace to log all attempts to open files, then you can at least find out what places it is looking for things :-).
-- http://home.comcast.net/~tomhorsley/wisdom/braindump/darwin.html
On Sat, Oct 30, 2010 at 01:45:14PM -0400, Tom Horsley wrote:
On Sat, 30 Oct 2010 13:08:38 -0400 David A. De Graaf wrote:
Can anyone give a clue how to access this very well hidden private key? Google can't.
A substitute for documentation can sometime be found by running the program under strace to log all attempts to open files, then you can at least find out what places it is looking for things :-).
Thanks, Tom, but further depths of googling led me to discover <doc>/README.nss where I found a hint.
The whole NSS password mess can be bypassed by NOT supplying a password when creating the NSS db, eg
certutil -N -d /etc/ipsec.d (just hit enter when prompted for a password)
Then create the RSA key without mentioning the --password option: ipsec newhostkey --configdir /etc/ipsec.d \ --output /etc/ipsec.d/ipsec.secrets and continue normally to create the net2net.conf file containing the left and right rsasigkey's.
My tunnel now connects properly. Eureka.
As an aside, I wish we didn't have to find "A substitute for documentation". In the openswan case we have too much. Too much to repair when change happens. The Freeswan Project, before its demise, had writers who seemed to be English majors, and left us with tons of glorious prose that was a joy to read. Unfortunately, when somebody decides to add another obscure and impenetrable layer of "security", they don't have the patience to fix the documentation. Instead, we are left with incorrect instructions plus a cryptic README.nss file.
The openswan system is complex enough. Having incorrect documentation is maddening. (Yeah, I know. I should fix it, or shut up.)
-
David A. De Graaf -
Tom Horsley