Am 22.08.2018 um 17:48 schrieb Sven Anders:
> Hello!
> 
> We are experiencing two problems when using CRLs.
> Our Linux systems runs strongSwan 5.6.2.
> 
> 
> 1) Because we want a hourly update of CRLs and the standard CRLs timeout
>    is 7 days, we created a cronjob, that fetches the latest CRL every hour.
> 
> This CRL file is named:
> 
>   /etc/ipsec.d/crls/COMPANY-SUB-CA01.crl
> 
> For a test, I additionally enabled CRL caching, but this did not
> make any difference:
> 
> charon {
>     cache_crls = yes
> }
> 
> 
> Here is the problematic run:
> 
>   Aug 22 16:54:44 2101120420063 charon: 15510[CFG] rereading crls from 
> '/etc/ipsec.d/crls'
>   Aug 22 16:54:44 2101120420063 charon: 15510[CFG]   loaded crl from 
> '/etc/ipsec.d/crls/0dff165cefbd2ddfb18f27e9215a4897b79f3008.crl'
>   Aug 22 16:54:44 2101120420063 charon: 15510[LIB]   crl #75 is not newer - 
> existing crl #75 retained
>   Aug 22 16:54:44 2101120420063 charon: 15510[CFG]   loaded crl from 
> '/etc/ipsec.d/crls/2d07eba139f0caad8a5ef7b87d542c46bbcd48ab.crl'
>   Aug 22 16:54:44 2101120420063 charon: 15510[LIB]   crl #02 is not newer - 
> existing crl #02 retained
>   Aug 22 16:54:44 2101120420063 charon: 15510[CFG]   loaded crl from 
> '/etc/ipsec.d/crls/48db6c1436fcdce1dc14b91619344b669e4dee6c.crl'
>   Aug 22 16:54:44 2101120420063 charon: 15510[LIB]   crl #01:62:32 is not 
> newer - existing crl #01:62:32 retained
>   Aug 22 16:54:44 2101120420063 charon: 15510[CFG]   loaded crl from 
> '/etc/ipsec.d/crls/COMPANY-SUB-CA01.crl'
>   Aug 22 16:54:44 2101120420063 charon: 15510[LIB]   crl #77 is newer - 
> existing crl #75 replaced
> 
> As you can see here, the manually updated CRL is newer (#77) and strongSwan
> replaces the old one (#75) by this new version. This seems to be correct.
> 
> In the new (#77) CRL I have the following entry:
> 
>   Serial Number: 2500000075E60D6340C615C22D000100000075
>          Revocation Date: Aug 22 16:49:00 2018 GMT
>          CRL entry extensions:
>              X509v3 CRL Reason Code:
>                  Certificate Hold
> 
> Now, if I try to connect, I get the following output and the user is accepted.
> But this is wrong, because the certificate is on hold!
> 
>   Aug 22 16:54:53 2101120420063 charon: 15504[CFG]   crl is valid: until Aug 
> 30 04:58:47 2018
>   Aug 22 16:54:53 2101120420063 charon: 15504[CFG]   using cached crl
>   Aug 22 16:54:53 2101120420063 charon: 15504[CFG]   fetching crl from 
> 'http://ca.company-group.local/CertEnroll/COMPANY-SUB-CA01+.crl' ...
>   Aug 22 16:54:53 2101120420063 charon: 15504[LIB]   sending request to 
> 'http://ca.company-group.local/CertEnroll/COMPANY-SUB-CA01+.crl'...
>   Aug 22 16:54:53 2101120420063 charon: 15504[CFG]   fetching crl from 
> 'http://ca.COMPANY.net/CertEnroll/COMPANY-SUB-CA01+.crl' ...
>   Aug 22 16:54:53 2101120420063 charon: 15504[LIB]   sending request to 
> 'http://ca.COMPANY.net/CertEnroll/COMPANY-SUB-CA01+.crl'...
>   Aug 22 16:54:53 2101120420063 charon: 15504[LIB] libcurl request failed 
> [60]: SSL certificate problem, verify that the CA cert is OK. Details:
>   Aug 22 16:54:53 2101120420063 charon: 15504[LIB] error:14090086:SSL 
> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
>   Aug 22 16:54:53 2101120420063 charon: 15504[CFG] crl fetching failed
>   Aug 22 16:54:53 2101120420063 charon: 15504[CFG] certificate status is good
>   Aug 22 16:54:53 2101120420063 charon: 15504[CFG]   certificate "DC=local, 
> DC=company-group, CN=COMPANY-SUB-CA01" key: 4096 bit RSA
>   Aug 22 16:54:53 2101120420063 charon: 15504[CFG]   using trusted ca 
> certificate "CN=COMPANY-ROOT-CA01"
>   Aug 22 16:54:53 2101120420063 charon: 15504[CFG] checking certificate 
> status of "DC=local, DC=company-group, CN=COMPANY-SUB-CA01"
>   Aug 22 16:54:53 2101120420063 charon: 15504[CFG] ocsp check skipped, no 
> ocsp found
>   Aug 22 16:54:53 2101120420063 charon: 15504[CFG]   using trusted 
> certificate "CN=COMPANY-ROOT-CA01"
>   Aug 22 16:54:53 2101120420063 charon: 15504[CFG]   crl correctly signed by 
> "CN=COMPANY-ROOT-CA01"
>   Aug 22 16:54:53 2101120420063 charon: 15504[CFG]   crl is valid: until Jun 
> 05 21:52:45 2028
>   Aug 22 16:54:53 2101120420063 charon: 15504[CFG]   using cached crl
>   Aug 22 16:54:53 2101120420063 charon: 15504[CFG] certificate status is good
>   Aug 22 16:54:53 2101120420063 charon: 15504[CFG]   certificate 
> "CN=COMPANY-ROOT-CA01" key: 4096 bit RSA
>   Aug 22 16:54:53 2101120420063 charon: 15504[CFG]   reached self-signed root 
> ca with a path length of 1
>   Aug 22 16:54:53 2101120420063 charon: 15504[IKE] authentication of 
> 'testu...@company.de' with RSA signature successful
> 
> If I restart strongSwan the user is denied correctly:
> 
>   certificate was revoked on Aug 22 16:52:00 UTC 2018, reason: certificate 
> hold
> 
> Where is my fault and can somebody explain it?
> 
> 
> 2) And we have another problem with delta CRLs:
> 
> As I understand strongSwan is supporting delta CRLs. The following line in 
> the logfile
> shows, that strongSwan correctly fetches the (delta) CRL:
> 
>   Aug 22 16:00:53 2101120420063 charon: 30400[CFG]   fetching crl from 
> 'http://ca.company-group.local/CertEnroll/COMPANY-SUB-CA01+.crl' ...
> 
> And the delta CRL has an entry with reason "remove from crl" in it.
> 
>   Aug 22 16:01:43 2101120420063 charon: 30400[CFG]   using trusted 
> certificate "DC=local, DC=company-group, CN=COMPANY-SUB-CA01"
>   Aug 22 16:01:43 2101120420063 charon: 30400[CFG]   crl correctly signed by 
> "DC=local, DC=company-group, CN=COMPANY-SUB-CA01"
>   Aug 22 16:01:43 2101120420063 charon: 30400[CFG]   crl is valid: until Aug 
> 29 04:02:43 2018
>   Aug 22 16:01:43 2101120420063 charon: 30400[CFG]   using cached crl
>   Aug 22 16:01:43 2101120420063 charon: 30400[CFG]   certificate "DC=local, 
> DC=company-group, CN=COMPANY-SUB-CA01" key: 4096 bit RSA
>   Aug 22 16:01:43 2101120420063 charon: 30400[CFG]   using trusted ca 
> certificate "CN=COMPANY-ROOT-CA01"
>   Aug 22 16:01:43 2101120420063 charon: 30400[CFG]   certificate 
> "CN=COMPANY-ROOT-CA01" key: 4096 bit RSA
>   Aug 22 16:01:43 2101120420063 charon: 30400[CFG]   reached self-signed root 
> ca with a path length of 0
>   Aug 22 16:01:43 2101120420063 charon: 30400[CFG]   using trusted 
> certificate "DC=local, DC=company-group, CN=COMPANY-SUB-CA01"
>   Aug 22 16:01:43 2101120420063 charon: 30400[CFG]   crl correctly signed by 
> "DC=local, DC=company-group, CN=COMPANY-SUB-CA01"
>   Aug 22 16:01:43 2101120420063 charon: 30400[CFG]   crl is valid: until Aug 
> 24 04:11:38 2018
>   Aug 22 16:01:43 2101120420063 charon: 30400[CFG] certificate was revoked on 
> Aug 22 14:01:35 UTC 2018, reason: remove from crl
>   Aug 22 16:01:43 2101120420063 charon: 30400[CFG]   using cached crl
>   Aug 22 16:01:43 2101120420063 charon: 30400[IKE] no trusted RSA public key 
> found for 'testu...@company.de'
> 
> But as you can see here, the user is denied.
> 
> What happened here? Is the (delta) reason "remove from crl" misinterpreted as 
> an
> revocation reason?

I took a look at the sources, but I did not found any special handling of the 
"Remove from CRL"
type. It seems to be handled like any other type.

Can anybody confirm this?

Any can somebody explain the first described behaviour, please?

Regards
 Sven Anders

-- 
 Sven Anders <and...@anduras.de>                 () UTF-8 Ribbon Campaign
                                                 /\ Support plain text e-mail
 ANDURAS intranet security AG
 Messestrasse 3 - 94036 Passau - Germany
 Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
  - Benjamin Franklin

<<attachment: anders.vcf>>

Reply via email to