Hi,
I noticed in Fedora 38 several Microsoft and Symantec root certificates that I don’t trust a bit.
What is the proper procedure to remove them from ‘trusted’ and move them to a new ‘untrusted’ area dor they can be brought back if need be?
1 Like
First you should be really sure this doesnt cause any trouble. There may be software, drivers, repositories etc. that use this certificate.
But understandable you may want to remove them.
Its better to not rm them but just move them somewhere else. Do this with unneeded repositories too.
enter a sudo shell in your Terminal:
sudo -i
cd /etc/pki/ca-trust/extracted/pem/
ls
cat README
There are more certificates, I could not find any from microsoft. It seems that often there are multiple certificates in one file, in that case you need to edit that file.
Maybe there is a better way though, as this could very easily break lots of things.
You will want to copy the files first, before changing them
Hi,
I moved them on MS Windows months ago without any problem. Microsoft is not a root authority and Symantec had been found guilty of fraud using fake root certificates in the past. Which means either can act as MITM with the consequences you can imagine.
On Fedora, I already looked into this and there is nothing in /etc/pki/ca-trust/extracted/pem/.
Instead, they are all in a bundle: /usr/share/pki/ca-trust-source/ca-bundle.trust.p11-kit and extracting them manually would be to say the least error prone.
Any suggestion on a way to get them extracted and where to move them?
The only thing clear is how to rebuild the database.
Could it be on purpose that it is so complicated to do? On Debian, they are all already extracted in one directory so they are easy to move.
Thanks for your kind assistance.
usr/share/pki/ca-trust-source# grep -E "(Microsoft|Symantec)" ca-bundle.trust.p11-kit
label: "Microsoft ECC Product Root Certificate Authority 2018"
label: "Microsoft ECC Product Root Certificate Authority 2018"
# Issuer: C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, CN = Microsoft ECC Product Root Certificate Authority 2018
# Subject: C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, CN = Microsoft ECC Product Root Certificate Authority 2018
label: "Microsoft ECC Root Certificate Authority 2017"
label: "Microsoft ECC Root Certificate Authority 2017"
# Issuer: C = US, O = Microsoft Corporation, CN = Microsoft ECC Root Certificate Authority 2017
# Subject: C = US, O = Microsoft Corporation, CN = Microsoft ECC Root Certificate Authority 2017
(...)
label: "Symantec Class 1 Public Primary Certification Authority - G6"
label: "Symantec Class 1 Public Primary Certification Authority - G6"
# Issuer: C = US, O = Symantec Corporation, OU = Symantec Trust Network, CN = Symantec Class 1 Public Primary Certification Authority - G6
# Subject: C = US, O = Symantec Corporation, OU = Symantec Trust Network, CN = Symantec Class 1 Public Primary Certification Authority - G6
label: "Symantec Class 2 Public Primary Certification Authority - G6"
label: "Symantec Class 2 Public Primary Certification Authority - G6"
# Issuer: C = US, O = Symantec Corporation, OU = Symantec Trust Network, CN = Symantec Class 2 Public Primary Certification Authority - G6
# Subject: C = US, O = Symantec Corporation, OU = Symantec Trust Network, CN = Symantec Class 2 Public Primary Certification Authority - G6
(...)
1 Like
that sounds bad! I think you should report this with a PR or bug report, as /usr/ is completely immutable on Atomic, which means not everyone could even change this manually. It should be best to remove them everywhere.
As for a manual test, look at the file and remove the lines, after that do a sudo update-ca-trust.
its weird, the file itself states to be based on nss/lib/ckfw/builtins/certdata.txt and nss/lib/ckfw/builtins/nssckbi.h, which are not full directory paths and I couldnt find them.
Otherwise you should totally change those files instead.
This is strange because that directory is supposed to contain the ‘trusted’ certificates extracted from the bundle kit you noted. The README says
This directory /etc/pki/ca-trust/extracted/pem/ contains
CA certificate bundle files which are automatically created
based on the information found in the
/usr/share/pki/ca-trust-source/ and /etc/pki/ca-trust/source/
directories.
All files are in the BEGIN/END CERTIFICATE file format,
as described in the x509(1) manual page.
Distrust information cannot be represented in this file format,
and distrusted certificates are missing from these files.
If your application isn't able to load the PKCS#11 module p11-kit-trust.so,
then you can use these files in your application to load a list of global
root CA certificates.
Please never manually edit the files stored in this directory,
because your changes will be lost and the files automatically overwritten,
each time the update-ca-trust command gets executed.
Please refer to the update-ca-trust(8) manual page for additional information.
Have you looked at the man page it references? Have you considered using the command it also references?
Manually editing any of those files is risky at best and may be fatal in some cases.
Not that strange. This README contains information for whomever build the p11-kit. It is assumed that the source directories are populated at this stage and the builder generates the p11-kit from there. For whatever reason, the sources are removed before the rpm we install is created.
Therefore without the sources, I’m totally unable to regenerate a valid p11-kit file. And there’s no documentation either on the internet. Kinda taboo subject.
Yes a did read the man pages. Again they are made for one that want to regenerate the p11-kit file, and for that, he needs to have the source. And that, I don’t.
I totally agree that manually editing a file that the formatting is obscure is totally risky and dangerous.
According to ‘man mk-ca-bundle’,
The mk-ca-bundle tool downloads the certdata.txt file from
Mozilla's source tree over HTTPS, then parses certdata.txt and
extracts certificates into PEM format. By default, only CA root
certificates trusted to issue SSL server authentication
certificates are extracted. These are then processed with the
OpenSSL command line tool to produce the final ca-bundle file.
The default outputfile name is ca-bundle.crt. By setting it to
'-' (a single dash) you will get the output sent to STDOUT
instead of a file.
The PEM format this scripts uses for output makes the result
readily available for use by just about all OpenSSL or GnuTLS
powered applications, such as curl and others.
The mk-ca-bundle file should be part of the curl package. However, in every linux distribution I looked at, it is nowhere to be found! I did find one though at https://github.com/curl/curl/blob/master/scripts/mk-ca-bundle.pl and I generated the wanted ca-bundle.crt. The format however is different than the p11-kit file and does not contain any public key as the p11-kit file does. Furthermore, there is no known way to extract date from the certdata.txt in separate files in order to populate the sources directories and regenerate the pii-kit file from that. Looks like a dead end…
It actually seems the files are installed in that location by a fedora package.
# dnf provides /etc/pki/ca-trust/extracted/pem/*
Last metadata expiration check: 0:52:07 ago on Sat 18 Nov 2023 09:45:36 AM CST.
ca-certificates-2023.2.60_v7.0.306-2.fc39.noarch : The Mozilla CA root certificate bundle
Repo : fedora
Matched from:
Filename : /etc/pki/ca-trust/extracted/pem/email-ca-bundle.pem
Filename : /etc/pki/ca-trust/extracted/pem/README
Filename : /etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem
Filename : /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
Is the ca-certificates package installed?
If not then maybe it should be installed (or reinstalled even if already there) so the files are properly in place.
2 Likes
Oh! Indeed. That is interesting. How I missed that? I’ll have a deeper look. Many thanks. Looks like the /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem file is generated because it contains certificates I made with mkcert too.
Remember that you should NOT edit or replace any of those files. You might add additional appropriate files, or otherwise be prepared to repeat any changes you make to the originals when an update occurs.
That is totally expected.
From the README:
This directory /etc/pki/ca-trust/extracted/ contains
CA certificate bundle files which are automatically created.
Please never manually edit the files stored in this directory,
because your changes will be lost and the files automatically overwritten,
each time the update-ca-trust command gets executed.
I guess you think [sarcasm] I did not read the README I posted above [/sarcasm]
I just was reminding you of what it said when I suggested to not make direct changes to those files.
LOL, fair enough
Allright, not simple but doable. Here’s the procedure.
# get the pkcs11 ids for the certificates to untrust
trust list
# extract them
trust extract --filter=certificates --filter="pkcs11:id=***;type=cert" --format=pem-bundle cert1.pem
trust extract --filter=certificates --filter="pkcs11:id=***;type=cert" --format=pem-bundle cert2.pem
(...)
trust extract --filter=certificates --filter="pkcs11:id=***;type=cert" --format=pem-bundle cert13.pem
# move them to blocklist, which has a higher priority than /usr/share/pki/ca-trust-source/ca-bundle.trust.p11-kit
mv cert*.pem /etc/pki/ca-trust/source/blocklist/
# update
update-ca-trust
# check that they are now untrusted
trust list --filter=blocklist
4 Likes
Interesting. 358 certificates on F38:
trust list | grep label | sort -u | wc -l
358
On Debian 12: 129! 3x less!