Hi, >> So no actual certificate files are necessary, as they are with older >> openswan? > > Correct. libreswan does not use /etc/ipsec.d/private or > /etc/ipsec.d/certs/ and does not need to use /etc/ipsec.d/cacerts/ > >> Is there a way to test this setup with just one side using libreswan >> and the other side using the ancient 1024-bit keys? > > You can always use your existing certificates and import those instead > of creating new ones. If you create new ones, you will have to export > it to pkcs12, then extract the pkcs12 into separate files to get the > key/cert/cacert to install on the openswan endpoint. Unless your > openswan endpoint is rhel/centos based in which case it already supports > nss so you can then just use pk12util to import it.
That's exactly what I ended up doing. Actually, what I did was import the existing certs into libreswan and just go head-first into it without testing, and it worked. I was concerned the old freeswan setup was so old that it wouldn't have supported the new key/cert. So now I have the old certs that are going to expire at the end of the year. Now that both sides are fedora20, I should be able to just recreate new certs on each side and import both on both sides, correct? One problem I did have along the way was when I tried to run "ipsec showhostkey --right", it would report the same key as when --left was provided instead. >> 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? > > Yes, it used to make a reference between the certificate and the private > key inside the nss database. We are working on no longer requiring that, > but for now you still need that : RSA entry in ipsec.secrets even if the > private key actually lives in the nss db and not in a > /etc/ipsec.d/private file. Yes, much simpler now. When you had originally said to create a hostkey.secrets file with the ": RSA friendlyname" in it, I thought you meant in addition (appended to) to the hostkey.secrets file, where all the rest of the RSA key info is located. That caused all kinds of problems until I figured out the private key was also stored in the NSS databases. It appears my processor indeed doesn't support AES/AVX2. How much overhead is required in software that otherwise would have been done by the processor? Sep 21 16:04:08 vpngx kernel: [ 10.096811] AVX2 or AES-NI instructions are not detected. Sep 21 16:04:08 vpngx kernel: AVX2 or AES-NI instructions are not detected. You've been very helpful, thanks so much. Alex _______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
