CAcert Code Development list.

[Wytze van der Raay <wytze AT cacert.org>]

Hi Ted,

On 4/10/19 9:02 PM, Bernhard Fröhlich wrote:
> ... 
> It did not come to my mind that someone might download the certificates
> without visiting the web page...

It is somewhat strange indeed, and I have no idea how serious these
applications are. The download frequency is pretty high as well, about
11000 downloads of root.crt and 7500 of class3.crt in about 100 hours.
And often from the same IP address within a few minutes from each other,
thus completely ignoring the fact that this data rarely changes.

> Probably the easiest solution for both
> problems will be to rename the old certificate files to something else (like
> root_X00.* and class3_XA418A.*) and copy the new files to the old names 
> also.
> So in the future we'll use root.* and class3.* for the "current" 
> certificates,
> and in addition make the whole history of certificates available using the
> names with attached serial numbers.

That sounds like a good solution indeed.

> Probably it is OK to handle this job under the same bugtracker case as 
> before
> and create a followup patch to this purpose. So, unless someone disagrees 
> I'd
> spare us the (small) overhead of creating a new case.

Fine with me.

> Karl-Heinz or Brian (or anyone else), can you just do this little change and
> create a commit to github?
> 
> 
> Wytze (and other critical admins), Dirk pointed me to another potential
> problem: The old certificates might still be part of the keychain the server
> sends out as part of SSL negotiation. Did you check this, or already handle
> this on the main server?

Yes, I have updated the keychain for the Apache2 webserver on www.cacert.org.

> IMHO this is a pure system administration job, so no development workflow is
> required, is this correct?

Yes, that is inside the sysadmin realm. But it's good when development
notes it.

> Otherwise I'd need some idea what we (development)
> should do, since web server configuration does not seem to be part of the
> cacert-devel repository,

Correct. It is constructed when setting up the CAcert chroot application
environment (e.g. after upgrading the OS release). The script for doing
so is mkchrootenv, which is found in
http://svn.cacert.org/CAcert/SystemAdministration/webdb/mkchrootenv , and has
been updated accordingly.

> and also not of
> https://infradocs.cacert.org/critical/webdb.html...

That file is still rather incomplete, it should indeed document all these
configuration issues. There is more info in the wiki, but it needs to be
transferred to infradocs.

Regards,
-- wytze

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature