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, > [email protected]" > > 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, > [email protected]" > > 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 [email protected] 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]== _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
