tteras/strongswan/src/libstrongswan/plugins/revocation, branch master tteras' strongSwan tree revocation: More accurately describe the flags to disable OCSP/CRL validation 2017-02-15T09:41:38+00:00 Tobias Brunner tobias@strongswan.org 2017-01-25T15:17:38+00:00 2de9bb30fea178bc27db146859a136a64c390013 These options disable validation as such, e.g. even from cached CRLs, not only the fetching. Also made the plugin's validate() implementation a no-op if both options are disabled. 
These options disable validation as such, e.g. even from cached CRLs, not
only the fetching.  Also made the plugin's validate() implementation a
no-op if both options are disabled.
revocation: OCSP and/or CRL fetching can be disabled 2016-12-30T17:12:53+00:00 Andreas Steffen andreas.steffen@strongswan.org 2016-12-30T17:12:53+00:00 e3f63c646914a24355eb63b7873123312549b7a4 






revocation: Cache valid CRL also if certificate is revoked
2016-10-11T15:18:22+00:00

Tobias Brunner
tobias@strongswan.org

2016-10-03T10:40:24+00:00

cee01fc9bf58ba513b13a1e003e8f8473117773d












revocation: Allow CRLs to be encoded in PEM format
2015-11-12T13:40:44+00:00

Tobias Brunner
tobias@strongswan.org

2015-11-11T13:26:00+00:00

e161238e8e9b14cbc3ba36e8897ec2473d36b0fd

Since the textual representation for a CRL is now standardized
in RFC 7468 one could argue that we should accept that too, even
though RFC 5280 explicitly demands CRLs fetched via HTTP/FTP to
be in DER format.  But in particular for file URIs enforcing that
seems inconvenient.

Fixes #1203.





Since the textual representation for a CRL is now standardized
in RFC 7468 one could argue that we should accept that too, even
though RFC 5280 explicitly demands CRLs fetched via HTTP/FTP to
be in DER format.  But in particular for file URIs enforcing that
seems inconvenient.

Fixes #1203.







plugins: Don't link with -rdynamic on Windows
2014-06-04T13:53:02+00:00

Martin Willi
martin@revosec.ch

2013-10-25T14:03:47+00:00

4163421f918d830585bfdccde0973d8801aad258












revocation: Log error if no OCSP signer candidate found
2014-03-31T13:02:17+00:00

Martin Willi
martin@revosec.ch

2014-03-31T12:53:15+00:00

94fb33bb8856973748d4377e0f3cdf3a8c2f27c3

Fixes evaluation of ikev2/ocsp-untrusted-cert.





Fixes evaluation of ikev2/ocsp-untrusted-cert.







revocation: Restrict OCSP signing to specific certificates
2014-03-31T12:40:33+00:00

Martin Willi
martin@revosec.ch

2014-03-25T13:34:58+00:00

91d71abb16a9b15bbcd7f6cbefb806408be3b92d

To avoid considering each cached OCSP response and evaluating its trustchain,
we limit the certificates considered for OCSP signing to:

- The issuing CA of the checked certificate
- A directly delegated signer by the same CA, having the OCSP signer constraint
- Any locally installed (trusted) certificate having the OCSP signer constraint

The first two options cover the requirements from RFC 6960 2.6. For
compatibility with non-conforming CAs, we allow the third option as exception,
but require the installation of such certificates locally.





To avoid considering each cached OCSP response and evaluating its trustchain,
we limit the certificates considered for OCSP signing to:

- The issuing CA of the checked certificate
- A directly delegated signer by the same CA, having the OCSP signer constraint
- Any locally installed (trusted) certificate having the OCSP signer constraint

The first two options cover the requirements from RFC 6960 2.6. For
compatibility with non-conforming CAs, we allow the third option as exception,
but require the installation of such certificates locally.







revocation: Don't merge auth config of CLR/OCSP trustchain validation
2014-03-31T12:40:33+00:00

Martin Willi
martin@revosec.ch

2014-03-27T09:59:29+00:00

a844b6589034ff53e845fb9013d69dac02385453

This behavior was introduced with 6840a6fb to avoid key/signature strength
checking for the revocation trustchain as we do it for end entity certificates.
Unfortunately this breaks CA constraint checking under certain conditions, as
we merge additional intermediate/CA certificates to the auth config.

As key/signature strength checking of the revocation trustchain is a rather
exotic requirement we drop support for that to properly enforce CA constraints.





This behavior was introduced with 6840a6fb to avoid key/signature strength
checking for the revocation trustchain as we do it for end entity certificates.
Unfortunately this breaks CA constraint checking under certain conditions, as
we merge additional intermediate/CA certificates to the auth config.

As key/signature strength checking of the revocation trustchain is a rather
exotic requirement we drop support for that to properly enforce CA constraints.







credmgr: introduce a hook function to catch trust chain validation errors
2013-07-18T14:00:30+00:00

Martin Willi
martin@revosec.ch

2013-07-09T09:55:32+00:00

4d7a762871f52dac5c7bd7808edc94a55dd40e1a












automake: replace INCLUDES by AM_CPPFLAGS
2013-07-18T12:59:19+00:00

Martin Willi
martin@revosec.ch

2013-07-17T12:45:39+00:00

19cb07b89050c0e3ea6a11e1914318c4ff1284b5

INCLUDES are now deprecated and throw warnings when using automake 1.13.
We now also differentiate AM_CPPFLAGS and AM_CFLAGS, where includes and
defines are passed to AM_CPPFLAGS only.





INCLUDES are now deprecated and throw warnings when using automake 1.13.
We now also differentiate AM_CPPFLAGS and AM_CFLAGS, where includes and
defines are passed to AM_CPPFLAGS only.