[strongSwan] Problems with CRLs

Discussion:

Sven Anders

2018-08-22 15:48:19 UTC

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 '***@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 '***@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?

Regards
Sven Anders
--
Sven Anders <***@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

Sven Anders

2018-08-27 21:32:30 UTC

Permalink

Post by 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.
/etc/ipsec.d/crls/COMPANY-SUB-CA01.crl
For a test, I additionally enabled CRL caching, but this did not
charon {
cache_crls = yes
}
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.
Serial Number: 2500000075E60D6340C615C22D000100000075
Revocation Date: Aug 22 16:49:00 2018 GMT
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] 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
certificate was revoked on Aug 22 16:52:00 UTC 2018, reason: certificate hold
Where is my fault and can somebody explain it?
As I understand strongSwan is supporting delta CRLs. The following line in the logfile
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
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 <***@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

Sven Anders

2018-09-13 08:42:34 UTC

Permalink

Hello!

can nobody help me with this issue?
Or isn't the question worth it?

Regards
Sven

Post by Sven Anders

--
Sven Anders <***@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

Tobias Brunner

2018-09-13 08:55:41 UTC

Permalink

Hi Sven,

Post by Sven Anders
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

Sven Anders

2018-09-13 11:22:07 UTC

Permalink

Post by Tobias Brunner
Hi Sven,

Post by Sven Anders
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.

Post by Tobias Brunner
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 <***@anduras.de> () 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

Continue reading on narkive:

Search results for '[strongSwan] Problems with CRLs' (Questions and Answers)

replies

This application Failed to start because iertutil.dll was not found Re-installing this may fix the problem.?

started 2010-02-27 02:34:48 UTC

security

replies

Pavilion dv6 hp problem with shutdown and restart.?

started 2011-03-11 22:12:49 UTC

laptops & notebooks

replies

Problems with PC freezing !!!?