CAcert Code Development list.

[Bernhard Fröhlich <bernhard AT cacert.org>]

Hi Wytze,

Am 10.04.2019 um 12:28 schrieb Wytze van der Raay:
> [...]
> One thing to note: since you have opted to add the re-signed root certificates
> with new names to the system and leave the old root certificates in place
> under their original names, it is still possible that users and applications
> retrieve the old root certificates. And observing the Apache2 access log,
> this is indeed the case -- clearly there are some applications which have
> these names/paths built-in. They will not benefit from this patch.
> To tackle this problem, you could consider to change the old certificates
> to copies of their new counterparts, so users and applications will retrieve
> the new version irrespective of the name/path used.
>
> Regards,
> -- wytze

I indeed gave a few thoughts to the file naming. I chose to accept 
Karl-Heinz' proposal to store the certificates under a new name mainly 
because this makes the change more obvious, and helped to avoid (a 
little bit of) confusion during development. Also it makes some sense to 
keep the old certificates easily accessible, in case someone needs them 
for research or forensic purposes.

It did not come to my mind that someone might download the certificates 
without visiting the web page... 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.

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.

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?

IMHO this is a pure system administration job, so no development 
workflow is required, is this correct? 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, and also not of 
https://infradocs.cacert.org/critical/webdb.html...

Kind regards
Ted
;)

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