[strongSwan] Problems with CRLs

Sven Anders anders at anduras.de
Mon Aug 27 23:32:30 CEST 2018


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 'testuser at 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 'testuser at 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 <anders at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: anders.vcf
Type: text/x-vcard
Size: 339 bytes
Desc: not available
URL: <http://lists.strongswan.org/pipermail/users/attachments/20180827/6572b68e/attachment.vcf>


More information about the Users mailing list