[strongSwan] RFC 4325 support - Authority Information Access CRL Extension
andreas.steffen at strongswan.org
Mon Jan 9 07:52:53 CET 2012
On 05.01.2012 08:19, ABULIUS, MUGUR (MUGUR) wrote:
> Hi Andreas,
> Happy New Year to all at the strongSwan team!
> Sorry to ask again. I am confused about the sentence:
>> the only alternative to extracting http CDPs from end entity
>> certificates is to define additional CDPs in ipsec.conf in a
>> special ca section
> Is this sentence true only in relation with AIA extension (RFC 4325),
> or it is a general strongSwsan statement for retrieving CRLs?
> Assuming that a X.509 certificate has a CDP extension but ***NOT***
> an AIA extension, do you mean that strongSwan can't retrieve the CRL
> unless the CDP is (also) specified in ipsec.conf (it is already
> specified inside X.509 certificate)?
No, CDP extensions in certificates are always processed and
don't require a ca section in ipsec.conf. AIA extensions can only
be used for OCSP URIs and don't require a ca section either.
ca sections in ipsec.conf are only used to define additional CDPs
and/or OCSP URIs.
> In any case, and regardless the answer to previous question, we need
> to address the validation of retrieved CRL that was signed by a
> specific CA (CA1). My assumption is that strongSwan needs to be
> commissioned with the certificate of CA1 in order to be able to
> validate the CRL.
> So the question: By which ipsec.conf option should be specified and
> in which directory should be present the certificate of CA1 to be
> used by strongSwan for CRL validation.
The CA certificates to be used for CRL validation must either be
stored in /etc/ipsec.d/cacerts or can be defined together with
additional CDPs in a ca section in ipsec.conf.
> Thank you Mugur
Andreas Steffen andreas.steffen at strongswan.org
strongSwan - the Linux VPN Solution! www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4489 bytes
Desc: S/MIME Cryptographic Signature
More information about the Users