Project

General

Profile

Bug #33

ikev2/crl-revoked scenario broken

Added by Martin Willi almost 14 years ago. Updated almost 14 years ago.

Status:
Closed
Priority:
High
Assignee:
Martin Willi
Category:
charon
Target version:
4.2.0
Start date:
Due date:
Estimated time:
Affected version:
5.9.2
Resolution:

Description

it seems that changeset 3613 broke the crl-revoked scenario:

: 10[CFG] fetching crl from 'http://crl.strongswan.org/strongswan.crl' ...
: 10[CFG] using trusted certificate "C=CH, O=Linux strongSwan, CN=strongSwan Root CA"
: 10[CFG] crl is trusted: good signature
: 10[CFG] fetched crl is valid
: 10[CFG] certificate was revoked on Dec 26 13:54:23 UTC 2004, reason: unspecified
: 10[CFG] fetching crl from 'http://crl.strongswan.org/strongswan.crl' ...
: 10[CFG] using trusted certificate "C=CH, O=Linux strongSwan, CN=strongSwan Root CA"
: 10[CFG] crl is trusted: good signature
: 10[CFG] fetched crl is valid
...
...repeated another 10 times
...
: 10[IKE] no trusted public key found for ''
: 10[AUD] authentication of '' with RSA signature failed
: 10[IKE] peer supports MOBIKE
: 10[ENC] generating IKE_AUTH response 1 [ N(AUTH_FAILED) ]

moon.daemon.log (9.01 KB) moon.daemon.log responder moon's log file Martin Willi, 19.03.2008 12:42
moon.daemon.2.log (16.8 KB) moon.daemon.2.log log file for ikev2/ocsp-revoked scenario Martin Willi, 19.03.2008 17:59

History

#1 Updated by Martin Willi almost 14 years ago

ikev2/ocsp-revoked scenario is broken in the same way, too

#2 Updated by Martin Willi almost 14 years ago

  • Status changed from New to Closed
  • Affected version set to fixed

r3613 did not introduced new problems, but it fixed the check_certificate() return value. While the behavior was correct, the complete trustchain still got verified.

The refactored trustchain verification from r3622 should address this problem and abort whenever a revoked certificate is found.

Please confirm...

Also available in: Atom PDF