Description of problem: Qt will normally load the default openssl root CA certificate bundles from /etc/ssl/certs/. However if any additional CA hashes have been added to this folder (for instance to support internal CA's) then the default bundles do not get loaded, and any encrypted comms will fail. This is easily reproducible with example code from the Qt project. Version-Release number of selected component (if applicable): Have verified this behaviour with Qt 4.8.5 & 5.1.1 under Fedora 19. How reproducible: Very Steps to Reproduce: 1. Vanilla F19 VM 2. Install necessary development tools 3. Add an additional certificate hash to /etc/ssl/certs/ 4. Build the fancybrowser Qt example application 5. Launch fancybrowser and browse to any https site Actual results: Browsing to site will fail Expected results: Browsing to site should work Additional info: Running under strace when no certificate hashes are present shows that the default certificate bundle is opened, and additional debugging within the Qt application will show the full list of root CA's. Running under strace when any certificate hashes are present shows that the very first hash file in that folder is opened, and nothing else. Additional debugging within the Qt application will show that no root CA's have been loaded.
I believe Qt currently only hard-codes loading of /etc/ssl/certs/ca-bundle.crt What do you mean exactly by "additional CA hashes have been added to this folder"?
See also related bug #521911 for some history
If I've got a private root CA (say used for signing intranet web pages), the way I'd get openssl to trust it would be to put a hash for this root certificate in the /etc/ssl/certs/ folder. So in the above folder I'd have (for instance) a certificate file "InternalRootCA.cer", and then create a symbolic link using the following command; ln -s InternalRootCA.cer `openssl x509 -hash -noout -in InternalRootCA.cer`.0 which would give me a symbolic link named (for instance) 4596471e.0 The problem I'm seeing with Qt, is that if any of these hash files are present, the first hash file gets opened but nothing else, so the main certificate bundle ca-bundle.crt never gets read. As soon as I rename all the .0 files to a different extension then Qt starts loading ca-bundle.crt correctly again.
Looking at the source for QSslSocketPrivate::ensureCiphersAndCertsLoaded(), if it finds any files that match a regex for the hash files, it assumes all certificates will be loaded on demand (from hashes) & never loads the system certificates. I'd say this is a bug, unless I'm missing a better way to add new root certs to openssl under Fedora? Surely it wouldn't be to edit the distro supplied bundle?
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
triaging rawhide/rfe
Just ran into this issue on Fedora 23.
Just ran into this issue on Fedora 29
Just ran into this issue on CentOS 8 TL;DR workaround: ```bash #remove certificates hashes sudo rm -rf /etc/pki/tls/certs/*.0 # run whatever command impacted by the bug # for example Jetbrains toolbox should work fine now, see https://youtrack.jetbrains.com/issue/ALL-1224 ``` To bring back certificates hashes in case they are needed for other software: ```bash sudo yum -y install openssl-perl sudo c_rehash ```
*** Bug 1573468 has been marked as a duplicate of this bug. ***