openswan is unusable

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. -- David A. De Graaf DATIX, Inc. Hendersonville, NC dad(a)datix.us www.datix.us