Don’t just append the /etc/ssl/certs/ca-certificates.crt or the /etc/ssl/certs/ca-bundle.crt.
Not long ago, I thought that it didn’t matter. I figured since the update-ca-trust command just updated the bundle, I might as well skip a step and go directly. I was wrong. Don’t do it. I guess that’s why people actually have processes and directions to follow.
The files are not meant to be edited manually. They are generated by the update-ca-trust or update-ca-certificates commands, which scan the /etc/pki/ca-trust/source/anchors or /usr/local/share/ca-certificates directories for custom CAs, and then concatenate them with the system CAs into a single file. If you edit these files directly, your changes will be overwritten the next time these commands are run. This could mean that your changes would not survive a patching if the ca-certificates package is updated.
The reason why you want to put the certificate issuers in /etc/pki/ca-trust/source/anchors/ or /etc/ssl/certs/ and use the update-ca-trust enable/extract commands is so that it can survive an update. If someone decides to patch the machine and there are other certificates being updated, the one that you appended to the bundle will get deleted.
Follow the process! For me, that’s basically:
1. Copy your custom CA file (in PEM format) to the /etc/pki/ca-trust/source/anchors directory on Red Hat-based systems, or the /usr/local/share/ca-certificates directory on Debian-based systems. Make sure the file has a .crt extension. 2. Run the update-ca-trust or update-ca-certificates command as root. This will regenerate the /etc/ssl/certs/ca-certificates.crt or the /etc/ssl/certs/ca-bundle.crt file with your custom CA included. 3. Restart any services or applications that use SSL/TLS connections, such as web servers, browsers, curl, etc. They should now trust your custom CA.