[strongSwan-dev] Handling of CRL updates different between Vici and ipsec rereadcrls

[Cole, Michael]

Our system distributes CRL out of band so we pass them onto strongswan using the vici load-cert() command.

This works fine usually as strongswan appears to use the last loaded CRL as the one to check when a new IKE connection is requested.
We run an HA pair and on recovery of a failed node, more than one CRL may be loaded via Vici to the recovered node and not always in the right order. This can result in strongswan using a CRL that is earlier that the latest CRL if the latest CRL was not the last loaded via Vici.
So revoked certificates may be unintentionally allowed again.

I note that if we put the CRLs into /etc/ipsec.d/crls and use ipsec rereadcrls followed by ipsec purgecrls then strongswan checks the crl numbers and/or dates and uses the latest.

Is there another way of achieving this using Vici, or even is it possible to have this functionality also available for CRLs loaded via vici ?

I appreciate that if were to check CRLs and order them before passing them to strongswan then this would resolve our problem but we want to avoid distributing the components involved with security around the system, the more strongswan can do itself the better for us

Mike Cole


Michael Cole | Cyber Security Services
CGI IT UK Ltd, 250 Brook Drive, Green Park, Reading, Berkshire, RG2 6UA UK
M: +44 791 789 3856
michael.cole at cgi.com<mailto:michael.cole at cgi.com> | cgi-group.co.uk
CGI IT UK Limited. A CGI Group Inc. Company
[Description: logo]

Registered Office: 250 Brook Drive, Green Park, Reading RG2 6UA, United Kingdom. Registered in England & Wales - Number 947968
CONFIDENTIALITY NOTICE: Proprietary/Confidential Information belonging to CGI Group Inc. and its affiliates may be contained in this message. If you are not a recipient indicated or intended in this message (or responsible for delivery of this message to such person), or you think for any reason that this message may have been addressed to you in error, you may not use or copy or deliver this message to anyone else. In such case, you should destroy this message and are asked to notify the sender by reply e-mail.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/dev/attachments/20151109/7bc25762/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 1816 bytes
Desc: image001.jpg
URL: <http://lists.strongswan.org/pipermail/dev/attachments/20151109/7bc25762/attachment.jpg>