Re: [strongSwan] Problems with CRLs

2018-09-13 Thread Sven Anders
Am 13.09.18 um 10:55 schrieb Tobias Brunner:
> Hi Sven,
> 
>> can nobody help me with this issue?
> 
> What more is there?  You already had a look a the source code and found
> it's not supported, so...

Maybe a second look?
It's not my source code, so I could be wrong.

And I think it's not an "it's not supported issue" rather than an "it's an 
error issue".
If anybody will confirm this, I would open a bug for it.

> And regarding the first one, there is an in-memory certificate/CRL cache
> (may be flushed with the `ipsec purge*` commands).

I will look into it.

Thanks!

Sven

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

Rechtsform: Aktiengesellschaft - Sitz: Passau - Amtsgericht: Passau HRB 6032
Mitglieder des Vorstands: Dipl.-Inf. Sven Anders, Dipl.-Inf. Marcus Junker
Vorsitzender des Aufsichtsrats: RA Mark Peters
<>

Re: [strongSwan] Problems with CRLs

2018-09-13 Thread Tobias Brunner
Hi Sven,

> can nobody help me with this issue?

What more is there?  You already had a look a the source code and found
it's not supported, so...

And regarding the first one, there is an in-memory certificate/CRL cache
(may be flushed with the `ipsec purge*` commands).

Regards,
Tobias


Re: [strongSwan] Problems with CRLs

2018-09-13 Thread Sven Anders
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: 250075E60D6340C615C22D00010075
>>  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