Description of problem:
After upgrading from 2.6.22-1 to 2.6.24-1 openswan refuses to start any tunnels using public key authentication, simply reporting a cryptic error:
Apr 26 11:15:17 gate pluto: "us" #63: Can't find the private key from the NSS CERT (err -12285)
I have checked that the correct CKAIDNSS is listed in the secrets file for the key being used for the tunnel, and that a key with that ID exists in the NSS database. Indeed pluto confirms in the log when it starts that it has found the key:
Apr 26 11:05:55 gate pluto: loading secrets from "/etc/ipsec.d/uk.secrets"
Apr 26 11:05:55 gate pluto: loaded private key for keyid: PPK_RSA:AQPX7tEmF
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Update to 2.6.24-1
2. Note that tunnels no longer work
Tunnels don't work.
This is a bug introduced in 2.6.24 by upstream. They removed hadcoded "sql:" from pluto but not from rsasigkey and showhostkey. This is fixed in 2.6.25.
In the recent release, the default NSS database format has been changed to the old database format (that is no sql format). It is possible that you created your database with sql: prefix. As a work around, you can try exporting the following variable, and verify again if the problem persists.
Thanks for reporting this. I will update to the recent release soon.
I did create it with the sql: prefix, yes - as I recall when the switch to NSS happened there was no information available and everything just stopped working and eventually google found a posting on the openswan list with the commands to create an NSS database as sql:/etc/ipsec.d.
In fact I found the same posting yesterday when I ran into this problem and followed the same steps to create a new database, which didn't help because I still had the sql: prefix...
Adding NSS_DEFAULT_DB_TYPE="sql" to the init script does indeed solve the problem.
Thanks for the your feedback. For using NSS, there is a README.nss in Openswan that you can always refer. Now, the recent release does not assume the NSS sql database. So with the latest release or any future release, if you have created your database with "sql:" prefix, you should always remember to export NSS_DEFAULT_DB_TYPE="sql" . So that Openswan knows that the database is "sql:".
I found README.nss now - it's in the openswan-doc package rather than openswan and I didn't have that installed on the gateway machine where I was doing this.
Anyway, is there any way to migrate from an sql: database to a non sql: one without regenerating keys? There doesn't seem to be any way to export a bare private key from an NSS database? Indeed the idea that you would have a bare key without a certificate seems to rather upset the NSS developers judging from the mailing list thread I found.
I would suggest you to use NSS "sql" database format, as suggested to me by NSS developer. The reason to use non sql database by default is just to make sure the compatibility with the platforms that do not support the NSS sql db yet.
So for future, it is better to export the variable NSS_DEFAULT_DB_TYPE="sql" and use the NSS sql format.
I just updated the Openswan package in Fedora 11 to the recent release, and this should be available through bodhi in a few days.
Also to transfer the keys from one database to another database, you can always use pk12util commands.
I am closing this bz. Thanks for reporting the issue. If this issue is resurfaced, please reopen this bz.
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '11'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 11's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 11 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here: