[strongSwan] Probems with CRL-Fetching and Pluto

Daniel Riedemann stigmayta at googlemail.com
Wed Feb 17 20:24:38 CET 2010


Hi all,

maybe I got something wrong with the automatic fetching of CRLs via 
http, so I really need your help here...
I thought that pluto downloads the CRL from the configured URI every 60 
seconds (I have configured crlcheckinterval=60) no matter if pluto has 
already a valid CRL or not. But it seems that this is not the case... :(

At first I generated a CRL where the client certificate is valid and not 
revoked. The CRL is valid until 19th March 2010 19:09:43 (= 30 days). 
The connection from a Windows XP host with TheGreenBow VPN IPSec Client 
gets up as expected.
Here is the output from the pluto log:

Feb 17 19:39:52 vpn pluto[15520]: | crl list locked by 'verify_by_crl'
Feb 17 19:39:52 vpn pluto[15520]: | crl list unlocked by 'verify_by_crl'
Feb 17 19:39:52 vpn pluto[15520]: "roadwarrior-ikev1"[1] 192.168.1.22 
#1: crl not found
Feb 17 19:39:52 vpn pluto[15520]: | crl fetch request list locked by 
'add_crl_fetch_request'
Feb 17 19:39:52 vpn pluto[15520]: | crl fetch request added
Feb 17 19:39:52 vpn pluto[15520]: | crl fetch request list unlocked by 
'add_crl_fetch_request'
Feb 17 19:39:52 vpn pluto[15520]: | fetch thread wake call by 
'verify_by_crl'
Feb 17 19:39:52 vpn pluto[15520]: | fetch thread was woken up
Feb 17 19:39:52 vpn pluto[15520]: | ocsp fetch request list locked by 
'fetch_ocsp'
Feb 17 19:39:52 vpn pluto[15520]: | ocsp fetch request list unlocked by 
'fetch_ocsp'
Feb 17 19:39:52 vpn pluto[15520]: | crl fetch request list locked by 
'fetch_crls'
Feb 17 19:39:52 vpn pluto[15520]: | ca info list locked by 'fetch_crls'
Feb 17 19:39:52 vpn pluto[15520]:   fetching crl from 
'http://192.168.1.50/StrongSWAN_Root_CA.crl' ...
Feb 17 19:39:52 vpn pluto[15520]: |   sending http request to 
'http://192.168.1.50/StrongSWAN_Root_CA.crl'...
...
Feb 17 19:39:52 vpn pluto[15520]: | authcert list locked by 'insert_crl'
Feb 17 19:39:52 vpn pluto[15520]: | crl issuer cacert found
Feb 17 19:39:52 vpn pluto[15520]: | authcert list unlocked by 'insert_crl'
Feb 17 19:39:52 vpn pluto[15520]: | crl signature is valid
Feb 17 19:39:52 vpn pluto[15520]: | crl list locked by 'insert_crl'
Feb 17 19:39:52 vpn pluto[15520]: | crl list unlocked by 'insert_crl'
Feb 17 19:39:52 vpn pluto[15520]:   written crl file 
'/etc/ipsec.d/crls/b5f5fc93cabfced64cd9a22844a0bc28a4ad64a5.crl' (781 bytes)
Feb 17 19:39:52 vpn pluto[15520]: | we have a valid crl
Feb 17 19:39:52 vpn pluto[15520]: | ca info list unlocked by 'fetch_crls'
Feb 17 19:39:52 vpn pluto[15520]: | crl fetch request list unlocked by 
'fetch_crls'
Feb 17 19:39:52 vpn pluto[15520]: | next regular crl check in 60 seconds
...
Feb 17 19:39:57 vpn pluto[15520]: | crl list locked by 'verify_by_crl'
Feb 17 19:39:57 vpn pluto[15520]: | crl found
Feb 17 19:39:57 vpn pluto[15520]: | authcert list locked by 'verify_by_crl'
Feb 17 19:39:57 vpn pluto[15520]: | authcert list unlocked by 
'verify_by_crl'
Feb 17 19:39:57 vpn pluto[15520]: | crl signature is valid
Feb 17 19:39:57 vpn pluto[15520]: | serial number: 02
Feb 17 19:39:57 vpn pluto[15520]: | crl list unlocked by 'verify_by_crl'
Feb 17 19:39:57 vpn pluto[15520]: | crl is valid: until Mar 19 19:09:43 2010
Feb 17 19:39:57 vpn pluto[15520]: | certificate is good

After that pluto just writes:

Feb 17 19:40:52 vpn pluto[15520]: | *time to check crls and the ocsp cache
Feb 17 19:40:52 vpn pluto[15520]: | ocsp cache locked by 'check_ocsp'
Feb 17 19:40:52 vpn pluto[15520]: | ocsp cache unlocked by 'check_ocsp'
Feb 17 19:40:52 vpn pluto[15520]: | crl list locked by 'check_crls'
Feb 17 19:40:52 vpn pluto[15520]: | issuer: 'C=DE, ST=Sachsen, 
L=Leipzig, O=StrongSWAN Project, OU=StrongSWAN PKI, CN=StrongSWAN Root CA'
Feb 17 19:40:52 vpn pluto[15520]: | authkey: 
b5:f5:fc:93:ca:bf:ce:d6:4c:d9:a2:28:44:a0:bc:28:a4:ad:64:a5
Feb 17 19:40:52 vpn pluto[15520]: | 2590131 seconds left
Feb 17 19:40:52 vpn pluto[15520]: | crl list unlocked by 'check_crls'
Feb 17 19:40:52 vpn pluto[15520]: | ocsp fetch request list locked by 
'fetch_ocsp'
Feb 17 19:40:52 vpn pluto[15520]: | ocsp fetch request list unlocked by 
'fetch_ocsp'
Feb 17 19:40:52 vpn pluto[15520]: | crl fetch request list locked by 
'fetch_crls'
Feb 17 19:40:52 vpn pluto[15520]: | crl fetch request list unlocked by 
'fetch_crls'
Feb 17 19:40:52 vpn pluto[15520]: | next regular crl check in 60 seconds

After that I revoked the certificate from the Windows XP and updated the 
CRL on the http server.
If I close the tunnel and restart it on the Windows client pluto doesn't 
fetch the new CRL. Even if I delete the cached CRL in /etc/ipsec.d/crls 
pluto doesn't fetch the new one from the server... an "ipsec rereadcrls" 
doesn't help either. To load the new CRL I have to restart pluto...

So did I really get something wrong here and this behavior is intended?
Here is a mail from the mailing list why I thought pluto would behave an 
other way: 
https://lists.strongswan.org/pipermail/users/2009-August/003714.html

I hope you can shed some light on this.
Thank you very much in advance!

Regards,
Daniel


My ipsec.conf:
config setup
         plutodebug=all
         crlcheckinterval=60
         strictcrlpolicy=yes
         cachecrls=yes
         nat_traversal=yes
         charonstart=no
         plutostart=yes

ca StrongSWAN_Root_CA
         cacert=StrongSWAN_Root_CA.crt
         crluri="http://192.168.1.50/StrongSWAN_Root_CA.crl"
         auto=add

conn roadwarrior-ikev1
         authby=pubkey
         auth=esp
         type=tunnel
         keyexchange=ikev1
         auto=add
         compress=yes
         dpddelay=15
         dpdtimeout=60
         esp=aes256-sha1
         ike=aes256-sha1-modp2048
         rekey=yes
         ikelifetime=10800
         lifetime=3600
         reauth=yes
         margintime=180
         modeconfig=pull
         pfs=yes
         pfsgroup=modp2048
         left=%defaultroute
         leftcert=vpn.project.lan.crt
         leftfirewall=yes
         leftid=@vpn.project.lan
         leftsendcert=ifasked
         leftsubnet=10.0.0.0/8
         right=%any
         rightsourceip=172.16.0.1




More information about the Users mailing list