Bug 1310262

I just did test this with latest libreswan git version running el6 based system:

Feb 21 23:28:10 omout pluto[1027]:   loading crl file 'foobar.crl' (4250 bytes)

I don't see any problem. Are you absolutely sure about testing? 

How about restorecon -Rv /etc/ipsec.d/crls and retry. If you copy the crl from home directory and you forget to reset selinux context it won't work.

The libreswan code in rhel6 and rhel7 is identical. So I would also guess that possibly there is a missing selinux policy update for rhel6?

I feel a little bit confused now, because the scenario, which i described, is not reproducible anymore, but my, much more complicated, test fails on rhel-6 and passes on rhel-7. It's needed more investigation. SELinux context is ok.

note that the initscripts and service file call ipsec checknss which handles importing CRL data from /etc/ipsec.d/crls/ but only when we are converting from the old nss db format to the new nss sql format.

Once convered, the /etc/ipsec.d/crls/ and /etc/ipsec.d/cacerts directories are ignored.

Actually, all crls are being read from /etc/ipsec.d/crls/ on every startup. Libreswan doesn't use crls in /etc/ipsec.d/crls/ but imports them if there are any.

(In reply to Tuomo Soini from comment #5)
> Actually, all crls are being read from /etc/ipsec.d/crls/ on every startup.
> Libreswan doesn't use crls in /etc/ipsec.d/crls/ but imports them if there
> are any.

Not that I see. If you look at programs/ipsec/ipsec.in you will see the section of code at

    # import cacerts and crls

is inside the "check for old nss db" if statement

Sure. Scripting does import of current crl files to nss db when database is converted. But after that pluto still reads crl files directly.

Tuomo and I are looking into this issue. It seems a more complicated bug.

Hi,

I did some tests and I have some results. I hope it will be useful for you.

My test creates an old version of db, so on start, ipsec --checknss is called and crl file myca.crl is imported into the new version of database. This is true for both versions, rhel-6 and rhel-7. Rhel-6's libreswan does not read myca.crl anymore, but rhel-7's libreswan still read this file everytime it is started and prints 'loading crl file myca.crl' into the log file. 

I attached ipsec files from my test. You can copy it into the right place and start ipsec.

# service ipsec stop
# tar zxvf ipsec_data.tar.gz
# cd ipsec_data
# rm -rf /etc/ipsec.*
# cp -apr * /etc/
# restorecon -Rv /etc/ipsec.*
# service ipsec start
# ipsec auto --listcrls
# grep 'loading crl' /var/log/secure

# service ipsec stop
# rm /etc/ipsec.d/crls/myca.crl
# service ipsec start
# grep 'loading crl' /var/log/secure

# service ipsec start
# cp ipsec.d/crls/myca.crl /etc/ipsec.d/crls/
# restorecon -Rv /etc/ipsec.*
# service ipsec start
# grep 'loading crl' /var/log/secure

Created attachment 1130248 [details]
IPsec data files.

Another issue. ipsec auto --rereadcrls does not work on rhel-6 (and rhel-7). It is marked as obsolete, but I think it still should work. At least it is confusing when 'loading crl' message is printed, but nothing is happen.

# ls /etc/ipsec.d/
cacerts  cert9.db  certs  crls  key4.db  nsspassword  nsspassword2.txt  nsspassword.txt  pkcs11.txt  policies  private  v6neighbor-hole.conf
# ls /etc/ipsec.d/crls/
myca.crl
# ipsec auto --listcrls
000  
000 List of CRLs:
# ipsec auto --rereadcrls
002   loading crl file 'myca.crl' (307 bytes)
# ipsec auto --listcrls
000  
000 List of CRLs:

Fixed with upstream commit

https://github.com/libreswan/libreswan/commit/52149be911e14dc3f89d8d0c1e0742954a35dbba

note you can see CRLs within NSS using:

crlutil -L -d sql:/etc/ipsec.d