Bug 649420 - Openswan fails to read the certs from NSS DB (037 can not load certificate file ca_cert)
Summary: Openswan fails to read the certs from NSS DB (037 can not load certificate fi...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: openswan
Version: 5.5
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Paul Wouters
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-11-03 17:39 UTC by Robin R. Price II
Modified: 2018-11-14 16:40 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-03-20 02:44:39 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
ipsec barf (50.56 KB, text/plain)
2010-11-03 19:05 UTC, Robin R. Price II
no flags Details

Description Robin R. Price II 2010-11-03 17:39:17 UTC
Description of problem:

I created the following connection.
conn som_x509
left=10.78.98.239
leftcert="ipsec-db"
leftrsasigkey=%cert
right=10.78.104.103
rightcert="ca_cert"
type=transport
auth=esp
authby=rsasig
auto=add
esp=3des-md5
keyexchange=ike
ike=3des-sha1
rekey=no

[root@ipcbu-plat239 ipsec.d]# certutil -L -d /etc/ipsec.d
Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI
ipsec-db u,u,u

I tried to add the connection but fails since ca_cert is not uploaded to NSS DB and this is expected.

[root@ipcbu-plat239 ipsec.d]# ipsec auto --add som_x509
/usr/libexec/ipsec/addconn Non-fips mode set in /proc/sys/crypto/fips_enabled
037 can not load certificate file ca_cert

Now uploaded the ca_cert to NSS DB using the following command
[root@ipcbu-plat239 ipsec.d]# certutil -A -n ca_cert -t "c,c,c" -i cacerts/ipsec_remote.pem -f nsspassword -d .

Also verified that ca_cert is now imported to NSS DB using certutil command.

[root@ipcbu-plat239 ipsec.d]# certutil -L -d /etc/ipsec.d

Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI
ipsec-db u,u,u
ca_cert c,c,c

However when I try to add the connection using "ipsec auto --add som_x509", it fails to load ca_cert from NSS DB even though ca_cert is imported to NSS DB.

[root@ipcbu-plat239 ipsec.d]# ipsec auto --add som_x509
/usr/libexec/ipsec/addconn Non-fips mode set in /proc/sys/crypto/fips_enabled
037 can not load certificate file ca_cert

If I restart the openswan using "ipsec setup restart", we are able to load the ca_cert from NSS DB.


Additional info:

Spoke with Avesh.  He said he was working on a patch for this.

~rp

Comment 1 Avesh Agarwal 2010-11-03 18:19:59 UTC
can you also provide me *.secrets file please?, and any log files you have.

Comment 2 Robin R. Price II 2010-11-03 19:05:21 UTC
Created attachment 457556 [details]
ipsec barf

Comment 3 Robin R. Price II 2010-11-03 19:06:22 UTC
Avesh,

I have already requested these files for you but they have not seen them uploaded.  I sent an email to remind them.  I do however have a 'ipsec barf' output to upload.

~rp

Comment 4 Avesh Agarwal 2010-11-04 19:03:28 UTC
I have been investigating it. Initially I thought that the Openswan code may be at fault. But I have looked at the Openswan code flow, and it does not matter when a certificate is added to NSS db, it tries to read the certificate as evident from the message "037 can not load certificate file ca_cert", so it means Openswan tries to read but it can not. So It seemed to me that it may be related to NSS.

I talked with Bob (cc'ed on this bug) about it, and here is the reason. As we know that RHEL5.5 uses dbm (cert8) format for NSS db, so this is the limitation of dbm format to prevent any database corruption from more than one users accessing the database. So it seems to me that only option is to restart Openswan to read the new certs added to the db.

Comment 5 Robin R. Price II 2010-11-05 17:36:13 UTC
Avesh, but that might restart existing IPSEC connections on the system, which might not be accepted by end user/customers.  Can Openswan be "reloaded" or does it have to be a full restart?

~rp

Comment 6 Robin R. Price II 2010-11-16 21:00:55 UTC
"Actually that is the limitation of NSS dbm db. Another issue is that pluto initializes the the NSS db and opens it, so once it has opened the db, pluto does not have any way that the db has been changed as NSS does not send any indication."

Comment 9 RHEL Program Management 2012-01-09 14:11:39 UTC
This request was evaluated by Red Hat Product Management for inclusion in Red Hat Enterprise Linux 5.8 and Red Hat does not plan to fix this issue the currently developed update.

Contact your manager or support representative in case you need to escalate this bug.

Comment 11 RHEL Program Management 2012-04-19 11:50:44 UTC
This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux release.  Product Management has
requested further review of this request by Red Hat Engineering, for
potential inclusion in a Red Hat Enterprise Linux release for currently
deployed products.  This request is not yet committed for inclusion in
a release.

Comment 12 RHEL Program Management 2012-10-30 06:10:22 UTC
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 13 Paul Wouters 2013-03-20 02:44:39 UTC
While openswan can be sent a signal to reload, it currently does not reload the NSS. pluto_init_nss() is only called in main() on startup.

Although pluto _also_ reads CA certificates from /etc/ipsec.d/cacerts/ so a workaround could be to add a copy of the CAcert in pem format there, and issue:

   ipsec auto --rereadall


Upstream was notified about this issue and filed bug #77 for it to add an NSS reload to its reloading routines, but that will only work with NSS versions as shipped with RHEL6 or later.


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