CAcert System Admins discussion list

[Philipp Gühring <pg AT futureware.at>]

Hi,

This is, whats currently running in production on crl.cacert.org, its one script, run by cron, as far as I remember. I dont remember whether there is a copy on svn, do please ask the admins of crl.cacert.org to provide the script.

Best regards,
Philipp

"Andre Klärner" <kandre AT cacert.org> schrieb:

Hi Philipp,

On Wed 23.10.2013 01:40:23, Philipp Guehring wrote:

Am 2013-10-22 02:11, schrieb Andre Klärner:

My idea would be to setup crl.cacert.org and www.cacert.org/crl so that
they 301 reroute to appropriate mirrors, which than can also be two
files hosted at any willing site.

I guess that some clients might not be happy to be sent around with HTTP
301, some CRL clients are most likely really dumb. I had an OCSP client
that did not support HTTP-Virtualhosts, it just sent a one-line GET
request, which did not work through our Firewall back then (or something
...), so don´ t exp ect intelligent clients there.

Well, let's see what clients we got. My assumption is still, that most of
the users that blindly download the new crl are either software that
downloads the crl, "decompiles" it and stores it internally or cron'ed
wgets/curls that simply weren't configured to check.

I thought mostly of only rerouting clients that advertise themselves as
proper clients (like wget and curl) and of which we know they can handle
301s perfectly and continue serving the rest as usual. Maybe we can also
check the implementation of some of our high-frequent clients if they
support 301s.

My implementation-design would be […]

You want the download to be complete before you atomically replace the
CRLs, so that any concurrent downloads of the to-be-replaced CRL aren´t
delivering broken CRLs during the update mechanism.

My writeup was more or less ment as a really rough draft, I already had
this problem noted in my mind, but didn't bother to include all the stuff
that one might want to take care of later on.

I tried to implement the necessary logic on crl.cacert.org, as far as I
remember.
(Although Linux filesystems do not seem to offer atomic rename
replacements anymore lately, they seem to delete the original first, and
rename the new file aterwards)
And my solution was designed to verify (check the signature) of the CRL
after it has been downloaded from www.cacert.org and before it is
activated and replaces the older one. So broken downloads should be
filtered out that way. (I wanted to implement that, I am not sure at the
moment, whether I actually did it or not)

Cool, nice to hear that some implementation is already done. Is it
accessible anywhere yet?

Regards,
Andre