CAcert System Admins discussion list

[<ulrich AT cacert.org>]

Hi Wytze,
thnx for your quick response :)

probably there exist applications that don't support OCSP
so we have to take care for crl distribution
but is there a chance to install an incremental update?
fix current crl as master, and the new update revision
as an incremental crl on top of the base crl file ?!?

from http://tools.ietf.org/html/rfc5280
describes at least the
4.2.1.15. Freshest CRL (a.k.a. Delta CRL Distribution Point)
mechanism ...

currently I have no time to dig into this topic :-P

from my understanding, if we can move forward this such
an idea, we probably have to update the cps first, can we ?!?


regards, uli   ;-)

-----Original Message-----
From: Wytze van der Raay 
[mailto:wytze AT cacert.org]
 
Sent: Wednesday, April 10, 2013 4:57 PM
To: 
ulrich AT cacert.org
Cc: 
cacert-sysadm AT lists.cacert.org
Subject: Re: FW: crl-download


Hi Ulrich,

On 10.04.2013 16:21, 
ulrich AT cacert.org
 wrote:
> one late issue after the server migration ?!?

No, this has nothing to do with the migration of the webdb server.
The CRL server is running on a separate server which has not changed
in the past 20 months or so.

> downloading crl error ...  ?!?

These problems are basically caused by overload -- not so much of the
server itself, but rather of the firewall in front (I think). On the
CRL server itself we do not see 403 errors. What we do see though is
an *immense* amount of traffic, typically 80 to 90 Gigabytes per day.

This is partly due to the rather large size of the revocation list,
in particular the http://crl.cacert.org/revoke.crl ;(over 5 megabytes),
but more so due to the large number of unintelligent clients which
attempt to retrieve this crl way more frequently than what is sensible.
For up-to-date revocation information, OCSP is the recommended protocol.

The size of the revocation list could be cut down considerably if we
can get agreement on dropping all the old entries in there, entries
for certificates which have expired anyway. While the RFCs allow this,
there has not been consensus within CAcert on implementing this.

As for unintelligent clients: since we have no control over them,
we might decide to get rid of the firewall, and implement a filter
directly on the crl server to block clients which attempt to reload
the CRL within some (tunable) number of hours. Currently this is not
possible, since the firewall (acting as a proxy) hides the clients
for the server.

Regards,
-- wytze


> -----Original Message-----
> From: Andreas Neumann 
> [mailto:andreas.neumann AT tu-ilmenau.de]
>  
> Sent: Wednesday, April 10, 2013 11:43 AM
> To: 
> cacert-de AT lists.cacert.org
> Subject: crl-download
> 
> 
> Moin,
> 
> der Versuch die aktuelle CRL herunterzuladen wird mit HTTP-Code 324
> (empty response) im Browser, bzw. HTTP-Code 403 (access forbidden) im
> wget beantwortet.
> 
> Es handelt sich um folgende Dateien:
> http://crl.cacert.org/class3-revoke.crl
> http://crl.cacert.org/revoke.crl
> 
> Links von http://www.cacert.org/index.php?id=3
> 
> Viele Grüße,
> Andreas

Attachment: smime.p7s
Description: S/MIME cryptographic signature