Bug 1021499

Summary:	Qt fails to load default root certificates when any cert hashes are present in /etc/ssl/certs/ folder (RFE)
Product:	[Fedora] Fedora	Reporter:	Jon Escombe <lists>
Component:	qt	Assignee:	Than Ngo <than>
Status:	ASSIGNED ---	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	brianwitt, colonelpanic42, diogo.castro, itamar, jgrulich, jreznik, kevin, mateusz.nowakowski, olze, ovasik, rdieter, smparrish, than
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jon Escombe 2013-10-21 12:20:27 UTC

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.

Comment 1 Rex Dieter 2013-10-21 14:14:28 UTC

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"?

Comment 2 Rex Dieter 2013-10-21 14:16:46 UTC

See also related bug #521911 for some history

Comment 3 Jon Escombe 2013-10-21 15:07:05 UTC

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.

Comment 4 Jon Escombe 2013-10-21 15:26:29 UTC

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?

Comment 5 Fedora End Of Life 2015-01-09 20:19:49 UTC

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.

Comment 6 Rex Dieter 2015-01-09 21:06:53 UTC

triaging rawhide/rfe

Comment 7 Brian Witt 2016-08-07 23:24:51 UTC

Just ran into this issue on Fedora 23.

Comment 8 oli 2019-01-26 15:13:11 UTC

Just ran into this issue on Fedora 29

Comment 9 matihost 2020-01-07 11:07:26 UTC

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
```

Comment 10 Colonel Panic 2020-06-20 00:01:10 UTC

*** Bug 1573468 has been marked as a duplicate of this bug. ***