Hi, >> - The RHEL7 site-to-site VPN docs say to place the leftrsasigkey and >> rightrsasigkey directly into the config file. I've been working with openssl >> to generate pkcs12 files from the key, certificate, and certfile. Then I'm >> using p12util to import the pkcs12 files directly into the NSS database. Is >> there any difference between the two methods? > > Yes, those are two different methods. One is called "raw keys > authentication" and the other one is "X.509 certificate based > authentication". Both methods can use RSA keys. > > An example with raw RSA keys can be seen: > > https://libreswan.org/wiki/Host_to_host_VPN > > An example with X.509 certificates: > > https://libreswan.org/wiki/Using_NSS_with_libreswan#Using_certificates_with_NSS
Using these instructions, it looks like I need the following to recreate the CA and certs for each side: # Create a certificate authority # certutil -S -k rsa -n "ExampleCA" -s "CN=Example CA Inc" -v 12 -t "C,C,C" -x -d /etc/ipsec.d # Create a user (host) cert for both sides: # certutil -S -k rsa -c "ExampleCA" -n "user1" -s "CN=User Common Name" -v 12 -t "u,u,u" -d /etc/ipsec.d So after running these commands, the certs and CA is in cert8.db, key3.db and secmod.db, correct? I can then export the CA and import it on the other side. Should I just recreate both host certs on the other side as well? And this automatically creates 2048-bit keys? So no actual certificate files are necessary, as they are with older openswan? Is there a way to test this setup with just one side using libreswan and the other side using the ancient 1024-bit keys? I'd like to be able to test this before rebuilding both sides from scratch because they're currently in production and separated by a driving distance. Do I need to worry about NAT traversal for the one side that's using a 192.168. network, or is that done automatically? >> - I'm also seeing the following message on the new fedora20 side after the >> connection is set up: >> Sep 18 20:51:01 vpntest pluto[4492]: "MYVPN" #1: unable to locate my >> private key for RSA Signature >> Sep 18 20:51:01 vpntest pluto[4492]: "MYVPN" #1: sending notification >> AUTHENTICATION_FAILED to 65.1.11.6:500 > > If you have imported the pkcs#12 file, you still need to place a line > in ipsec.secrets to tell pluto about the private key. It uses the "friendly" > name used when creating the pk12 file: > > : RSA "friendlyname" > > And in ipsec.conf you would have a left and/or right cert line, eg: > > leftcert=friendlyname I did have this in the ipsec.conf that I pasted here originally. Is this secrets file used when it's configured to use X.509 certificates? I'm wondering because I didn't have the friendlyname in the secrets file and I'm pretty sure the connection was established, as I was pretty sure I was able to connect to the remote side. Or does this AUTHENTICATION_FAILED message clearly indicate I wasn't connected? >> I have two secrets files - one I just created with ipsec newhostkey and I >> believe is wrong, and an existing hostkey.secrets file that was created >> years ago, which I believe is correct. It also references both files during >> startup: >> >> Sep 18 21:03:14 vpntest pluto[1256]: loading secrets from >> "/etc/ipsec.secrets" >> Sep 18 21:03:14 vpntest pluto[1256]: loading secrets from >> "/etc/ipsec.d/hostkey.secrets" >> Sep 18 21:03:14 vpntest pluto[1256]: loaded private key for keyid: >> PPK_RSA:AQPAcYrhb > > This seems to be one private key. So if it's loaded the private key, does it mean it's the correct private key, and that it's using it for this connection? >> Sep 18 21:03:14 vpntest pluto[1256]: loading secrets from >> "/etc/ipsec.d/righthost.example.com.secrets" > > This might not have loaded as expected? That is the new key that I just generated, which the other side has no knowledge about. >> conn %default > >> leftrsasigkey=%cert >> rightrsasigkey=%cert > > So you are using X.509.... So the raw RSA keys are not used. Does that mean the secrets file is not used? >> conn MYVPN > >> leftid="@C=US, ST=New Jersey, L=MyTown, O=My Company Inc, >> CN=lefthost.example.com" >> leftcert=lefthost > >> rightid="@C=US, ST=New Jersey, L=MyTown, O=My Company Inc, >> CN=righthost.example.com" >> rightcert=righthost > > > So you seem to be loading both certs on both ends. That means you do not > need to use a CA. But it also means you need to import those two > certificates into NSS on both sides. So to install your certificates > and keys, do this: Since you mentioned they are probably just 1024-bit, and since they are expiring at the end of the year anyway, I figured I could follow the steps for building a CA, as I've outlined above. > Don't forget the ipsec.secrest entry as described above. After starting > openswan/libreswan, run: ipsec auto --listall to see if you have both > certificates and one private key on each end. I've run --listall, and it looks like it found two keys but can't parse them? 000 List of Pre-shared secrets (from /etc/ipsec.secrets) 000 1: RSA (none) (none) 000 1: RSA (none) (none) The /etc/ipsec.secrets file just includes all the *.secret files from /etc/ipsec.d. This includes the one I just created and the original one without the friendlyname. Perhaps I don't fully understand the purpose of the secrets file. That's where the preshared keys are stored, correct? And I'm using X.509 certs, so the keys aren't used? Thanks, Alex > >> # Disable Opportunistic Encryption >> include /etc/ipsec.d/no_oe.conf > > > You can remove that and use oe=no in "config setup" on openswan. You > do not need oe= for libreswan. > > Paul _______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
