[strongSwan] Strongswan 4.5.1 sqlite database crl URI

[Andreas Steffen]

Oops, I got the wrong excerpt from the log file which
shows the fetching of a CRL defined by a CDP extracted
from the end entity certificate.

Here is the fetching of the CRL defined by the CDP from
the database:

May 14 21:36:08 moon charon: 14[CFG]

checking certificate status of "C=CH, O=Linux strongSwan, OU=Research, 
CN=Research CA"

fetching crl from 'http://crl.strongswan.org/strongswan.crl' ...
May 14 21:36:08 moon charon: 14[CFG]   using trusted certificate "C=CH, 
O=Linux strongSwan, CN=strongSwan Root CA"

crl correctly signed by "C=CH, O=Linux strongSwan, CN=strongSwan Root CA"

crl is valid: until Jun 13 17:32:37 2011

Regards

Andreas

On 07/07/2011 12:08 PM, Andreas Steffen wrote:
> Hello Fabrice,
>
> I'm testing the certificate_distribution_points table in the
> sql/multi-level-ca scenario, where moon needs the CDP for
> the intermediate Research and Sales CA certificates which
> are signed by the Root CA:
>
> http://www.strongswan.org/uml/testresults/sql/multi-level-ca/moon.ipsec.sql
>
> The table entry is:
>
> INSERT INTO certificate_distribution_points (
> ca, type, uri
> ) VALUES (
> 1, 1, 'http://crl.strongswan.org/strongswan.crl'
> );
>
> CRLs defined by http or ldap URIs are *not* fetched during the
> startup of the charon daemon, so ipsec listcrls doesn't show
> any entries. The fetching takes place when the first certificate
> from a given CA must be validated:
>
> http://www.strongswan.org/uml/testresults/sql/multi-level-ca/moon.daemon.log
>
>
> May 14 21:36:08 moon charon: 14[CFG]
>
> using certificate "C=CH, O=Linux strongSwan, OU=Research,
> CN=carol at strongswan.org"
>
> using untrusted intermediate certificate "C=CH, O=Linux strongSwan,
> OU=Research, CN=Research CA"
>
> checking certificate status of "C=CH, O=Linux strongSwan, OU=Research,
> CN=carol at strongswan.org"
>
> fetching crl from 'http://crl.strongswan.org/research.crl' ...
>
> After the fetching, ipsec listcrls shows the CRL:
>
> List of X.509 CRLs
>
> issuer: "C=CH, O=Linux strongSwan, CN=strongSwan Root CA"
> serial: 05
> revoked: 16 certificates
> updates: this May 14 17:32:37 2011
> next Jun 13 17:32:37 2011, ok
> authkey: 5d:a7:dd:70:06:51:32:7e:e7:b6:6d:b3:b5:e5:e0:60:ea:2e:4d:ef
>
> The log which was attached to your mail shows CDPs embedded into a
> certificate. For that case the CDP entries in the database are not
> needed.
>
> Best regards
>
> Andreasa
>
> On 07/07/2011 11:14 AM, CETIAD - Fabrice Barconnière wrote:
>> Hello,
>>
>> The crl file specified in URI (certificate_distribution_points table)
>> doesn't seem to be read.
>> ipsec listcrls command doesn't return, anything.
>> If i put the crl file in /etc/ipsec.d/crls/ directory and execute ipsec
>> rereadcrls, ipsec listcrls command gives the informations.
>>
>> Here is what we can see in database :
>> ####CA certificate
>> INSERT INTO "certificates"
>> VALUES(3,1,1,X'2D2D2D2D2D424547494E2043455254494649434154452D2D2D2D2D0A4D49494462444343416C536741774942416749514B545775474C30364D324E44754D477735436A33496A414E42676B71686B69473977304241515546414441320A4D517377435159445651514745774A6D636A454E4D4173474131554543684D455A323931646A45594D4259474131554541784D50556B464453553546494546480A556B6C42564556544D423458445441354D5449774F54457A4D6A59304D6C6F58445449774D54457A4D4441784D4441774D6C6F774E6A454C4D416B47413155450A42684D435A6E49784454414C42674E5642416F5442476476645859784744415742674E5642414D5444314A4251306C4F5253424252314A4A51565246557A43430A415349774451594A4B6F5A496876634E4151454242514144676745504144434341516F4367674542414C625A5836504E3433516F55725034556C33734E502B490A356F6C792B6C4A736159505235566F6B4237574975552B484358325639445675735064713433744A663243736968304F2B6654344D324B57492F36436B5247670A436861564A316433774231613731544D43666F69686A6B5975354E54494C6D5036432B584E4367647334615946345251574A64622B6D687142354E57556D72410A4E764A
6
>>
> 852374C5942744C6A35663276634F744C7A6C4C46434B375673757A2B79376A2B373632464A326B566A635854514D4656377A644E71494172453131770A39744364314969724F6C4836464732594368577630713647765350552B6B3651676D55732F6E3472482F5354372B3552534E70313837485A747368346D3364370A594F38766C5071625633773041784255485A7A62786A75702F3339634D6A6D57656E394C3752475543357242737A30722B526A5345494A4E36716334325045430A4177454141614E324D4851774551594A59495A49415962345167454242415144416741484D41384741315564457745422F7751464D414D4241663877485159440A5652304F424259454648713874476A3473614979524D6E51362F326542734A57415373444D41344741315564447745422F77514541774942686A416642674E560A48534D454744415767425236764C526F2B4C47694D6B544A304F76396E67624356674572417A414E42676B71686B6947397730424151554641414F43415145410A656C7136517136675376747876646E5A496253787935576E474C6F6B593155526C414A5562435849544365362B5155486C535166695A312B46657146427435610A5A443942523266484C625275324A6532364957654D626A767346583143666E4E763243725973532B47653
34
>
> 75456583574594D6350725049704B474F533747530A5859524647503835525A6776646D355544385936786367615147382B453955715A5A3656717963624F39784A696E3144364B6B646E6233534D2F3135705A53690A345A654A372B5A514C7471714C7855614739544875484F53553277306C34496756656E786468676D396F31473143474C746875747072444F42537448356238730A494A68534D726A7351776633327458367132346666676841633055556E76683750776F4D2F54492B6C50446349754F6B4B5674507968415239494D4D6A4768430A415A464B437247395350366F306B2F434E31787548673D3D0A2D2D2D2D2D454E442043455254494649434154452D2D2D2D2D0A');
>
>>
>>
>> INSERT INTO "identities"
>> VALUES(39,9,X'3036310B3009060355040613026672310D300B060355040A1304676F7576311830160603550403130F524143494E45204147524941544553');
>>
>>
>> INSERT INTO "identities"
>> VALUES(3111,11,X'7ABCB468F8B1A23244C9D0EBFD9E06C256012B03');
>>
>> INSERT INTO "certificate_authorities" VALUES(39,3);
>>
>> INSERT INTO "certificate_distribution_points"
>> VALUES(1,39,1,'http://crl1.igc.education.fr/agriates.crl');
>> INSERT INTO "certificate_distribution_points"
>> VALUES(2,39,1,'http://crl2.igc.education.fr/agriates.crl');
>>
>> Logs at ipsec listall command execution in log joined file.
>>
>>
>> Is there something wrong ?
>>
>> Regards,
>> Fabrice
>>

======================================================================
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)
===========================================================[ITA-HSR]==