Hello!
can nobody help me with this issue?
Or isn't the question worth it?
Regards
Sven
Am 27.08.18 um 23:32 schrieb Sven Anders:
> 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
