Description of problem: The majority of Linux distributions have a /etc/ssl directory with openssl.cnf and valid trust store. The valid trust store is either a cafile /etc/ssl/cert.pem in the form of a PEM bundle or a capath directory /etc/ssl/certs/ with hashed cert files. Red Hat platforms (CentOS, Fedora, RHEL) are the only major Linux distributions that don't have a fully configured /etc/ssl directory. On Fedora /etc/ssl directory is owned by ca-certificates and contains only a symlink certs -> /etc/pki/tls/certs. Red Hat platforms don't provide a hashed capath directory by default. $ rpm -qf /etc/ssl ca-certificates-2020.2.41-1.1.fc32.noarch $ ls -l /etc/ssl total 0 lrwxrwxrwx. 1 root root 16 Jun 17 01:00 certs -> ../pki/tls/certs For Python ecosystem and others, it would be helpful to turn /etc/ssl into a full OpenSSL configuration directory with openssl.cnf and trust store. This would make it easier to use static compiled binaries with embedded OpenSSL across distribution with additional workarounds. For example binaries wheels of PyCA cryptography (python-cryptography) and PyOpenSSL embed their own copy of OpenSSL. PyOpenSSL has extra code to detect the distribution-specific trust store. Conda and Golang require similar workarounds, e.g. https://golang.org/src/crypto/x509/root_linux.go I propose to add three additional symlinks to /etc/ssl cert.pem -> ../pki/ca-trust/extracted/pem/tls-ca-bundle.pem openssl.cnf -> ../pki/tls/openssl.cnf ct_log_list.cnf -> ../pki/tls/ct_log_list.cnf Version-Release number of selected component (if applicable): ca-certificates-2020.2.41-1.1.fc32.noarch How reproducible: Always
My PR https://src.fedoraproject.org/rpms/ca-certificates/pull-request/5 implements the additional symlinks.
I've visited this trough https://github.com/tiran/distro-truststore and https://github.com/psf/requests/issues/2966 The PR is merged. This can be closed then?
Thanks for the ping, Miro! The new symlinks are available in Fedora 34+ and RHEL 9. # . /etc/os-release # echo $NAME $VERSION_ID Fedora 34 # ls -l /etc/ssl total 0 lrwxrwxrwx. 1 root root 49 Jan 25 21:08 cert.pem -> /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem lrwxrwxrwx. 1 root root 18 Jan 25 21:08 certs -> /etc/pki/tls/certs lrwxrwxrwx. 1 root root 28 Jan 25 21:08 ct_log_list.cnf -> /etc/pki/tls/ct_log_list.cnf lrwxrwxrwx. 1 root root 24 Jan 25 21:08 openssl.cnf -> /etc/pki/tls/openssl.cnf # . /etc/os-release # echo $NAME $VERSION_ID Red Hat Enterprise Linux 9.0 # ls -l /etc/ssl total 0 lrwxrwxrwx. 1 root root 49 Feb 3 06:00 cert.pem -> /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem lrwxrwxrwx. 1 root root 18 Feb 3 06:00 certs -> /etc/pki/tls/certs lrwxrwxrwx. 1 root root 28 Feb 3 06:00 ct_log_list.cnf -> /etc/pki/tls/ct_log_list.cnf lrwxrwxrwx. 1 root root 24 Feb 3 06:00 openssl.cnf -> /etc/pki/tls/openssl.cnf
I kinda disagree with a lot of the basis for this, though adding more symlinks doesn't hurt *much*. "The majority" of distributions seems like an overly strong assertion, especially for /etc/ssl/cert.pem , which is what this PR actually did (a populated /etc/ssl/certs is more common, though we still do not have that). Per Miro's link, really only a few fairly niche distros have /etc/ssl/cert.pem . I looked into this extensively many years ago and filed some suggestions, none of which unfortunately were picked up. I would prefer we *get rid of* our /etc/ssl/certs directory as it does nothing but confuse people. See https://bugzilla.redhat.com/show_bug.cgi?id=1053882 (and https://www.happyassassin.net/posts/2015/01/12/a-note-about-ssltls-trusted-certificate-stores-and-platforms/ ) . It would've been nice if someone could've looked over that work, as I put quite a lot of effort into it.
sorry, I forgot we actually followed up a bit on the end of that bug before, never mind.