Bug 585881 - Upgrade to 2.6.24 stops openswan finding private keys
Upgrade to 2.6.24 stops openswan finding private keys
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: openswan (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: Avesh Agarwal
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-04-26 06:23 EDT by Tom Hughes
Modified: 2010-04-28 08:03 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-04-27 15:17:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tom Hughes 2010-04-26 06:23:15 EDT
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[12191]: "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[12191]: loading secrets from "/etc/ipsec.d/uk.secrets"
Apr 26 11:05:55 gate pluto[12191]: loaded private key for keyid: PPK_RSA:AQPX7tEmF

Version-Release number of selected component (if applicable):

openswan-2.6.24-1.fc11.x86_64

How reproducible:

Every time.

Steps to Reproduce:
1. Update to 2.6.24-1
2. Note that tunnels no longer work
  
Actual results:

Tunnels don't work.

Expected results:

Tunnels work.
Comment 1 Avesh Agarwal 2010-04-27 09:25:42 EDT
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.

export NSS_DEFAULT_DB_TYPE="sql" 

Thanks for reporting this. I will update to the recent release soon.
Comment 2 Tom Hughes 2010-04-27 09:41:01 EDT
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.
Comment 3 Avesh Agarwal 2010-04-27 09:53:44 EDT
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:".
Comment 4 Tom Hughes 2010-04-27 10:31:15 EDT
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.
Comment 5 Avesh Agarwal 2010-04-27 10:54:38 EDT
Hello Tom,

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.

Avesh
Comment 6 Avesh Agarwal 2010-04-27 10:56:04 EDT
Also to transfer the keys from one database to another database, you can always use pk12util commands.
Comment 7 Avesh Agarwal 2010-04-27 15:17:07 EDT
I am closing this bz. Thanks for reporting the issue. If this issue is resurfaced, please reopen this bz.
Comment 8 Bug Zapper 2010-04-28 08:03:25 EDT
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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Note You need to log in before you can comment on or make changes to this bug.