Bug 585881
Summary: | Upgrade to 2.6.24 stops openswan finding private keys | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Tom Hughes <tom> |
Component: | openswan | Assignee: | Avesh Agarwal <avagarwa> |
Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 11 | CC: | avagarwa, sgrubb |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2010-04-27 19:17:07 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Tom Hughes
2010-04-26 10:23:15 UTC
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. 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. 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 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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping |