Is there any reliable way to distrust a ca-certificate?

[sergeev917]

I want to manage the list of certificate authorities which are installed in my system.

A way to add custom certificates is present -- it is mentioned in the man page of update-ca-certificates(8) that all certificates from /usr/local/share/ca-certificates are automatically pushed into the trusted store.

But I've failed to find a convenient way to distrust (remove from trusted store) a certificate which goes with standard distribution. /etc/ca-certificates.conf file has a header that says "do not edit" and "automatically generated", nevertheless it is protected from silent rewrite with /etc/env.d/98ca-certificates.

The hooks in /etc/ca-certificates/update.d are invoked after all processing is done, so using it will lead to overcomplicated scheme where an update will take two passes over certificate store (since there is a generation of batch-file /etc/ssl/certs/ca-certificates.crt with all trusted certificates in place).

I tried to find any usefull information on the topic, but it seems that this is not popular theme.
Is there any way to do such task (and without hacks which will be broken after some updates are introduced)?

[Schnulli]

Hi
try out Seahorse, maybe it helps you, its a GUI App

regards

[gordonb3]

Seems to me you can delete whatever you don't want from /usr/share/ca-certificates and then run `update-ca-certificates --fresh`.

Obviously the untrusted CAs will return when you receive an update of app-misc/ca-certificates but you could mask that.

[sergeev917]

> Seems to me you can delete whatever you don't want from /usr/share/ca-certificates and then run `update-ca-certificates --fresh`.

It is not exactly a stable solution: it will break qcheck scans, also there will be a problem with quickpkg-packages.
And I want to receive updates of ca-certificates since it is obvioulsy good idea in the first place (for example, distrust some revoked certificate).
The additional problem here is that ca-certificates ebuild don't have user epatch in it, so the workaround goes away from /usr/portage/patch to local overlay, which is not that great.

[gordonb3]

A local overlay could still be auto generated from the regular portage tree. Simply sync with the corresponding part of the tree (/usr/portage/app-misc/ca-certificates), patch the ebuilds to accept your user patch/delete entries prior to merge and (re)generate the manifest.

[szatox]

I'd try revoking those certificates. You can do that with a certificate revocation list. Of course CRL that suits your purpose will be hard to find, so you have to create one.
To create CRL, you must be a certificate authority.
To be a certificate authority, you must poses a valid and trusted certificate.
Good news is, you can create that certificate with openssl, and then you can trust it. Gratz, you have just become your own certificate authority supporting one user (yourself!)

One thing I'm not sure with this way is whether or not you can revoke certificates issued by the 3rd parties. If you can... Well, revoking a certificate disables it permanently, so it should fix the problem for a long time: until a new certificate replaces the one you revoked.