KDE doesn't honor root certs chosen by ca-certificates

[Malte S. Stretz]

Currently ther kdelibs-package maintains an own copy of trusted root certs in /usr/share/kde4/config/ksslcalist. This could be generated by ca-certificates so that those settings are really globally available.

[Malte S. Stretz (mss)]

Hmmm... doesn't look so hard to create a package based on ca-certificates-java. I'll have a shot...

[James Westby (james-w)]

Hi,

I'm not sure why you think ca-certificates needs to change here?
What does it not do that you want it to do?

Can kdelibs not just be changed to use the list already generated in
/etc/ssl/certs?

Thanks,

James

[Malte S. Stretz (mss)]

@James: Nope, ca-certificates doesn't have to be changed, I didn't know that it already is modular enough. If you know how to remove a package from this bug, please do so with ca-certificates :)

And nope, it can't just use the list in /etc/ssl/certs because it uses an own ini-styled ca-"bundle". So I guess the easiest way to implement this is to create an extra package ca-certificates-kde (based on ca-certificates-java) which generates this list, put the default list from kde4libs into an extra package and make kde4libs-data depend on (kde4libs-data-cacerts || ca-certificates-kde). Oh, and maybe make those two packages conflict with each other. Sounds like a plan?

[James Westby (james-w)]

Hi,

Is kde's bundle different to /etc/ssl/certs/ca-certificates.crt?

Could it perhaps grow support for that type of bundle as well?

Thanks,

James

[Malte S. Stretz (mss)]

Yes, its different: Its not PEM-encoded but stored in an ini-file.

Maybe somebody could write a patch for kdelibs to use a PEM file instead but it seems like the SSL stuff is currently not well maintained in KDE itself and I doubt that such a patch would go in before 4.3. So for now the easiest (and quickest) way is to hook into ca-certificates with a custom generator.

[Malte S. Stretz (mss)]

Hm, this is really... convoluted. Seems like KDE uses (at least) two files: A PEM-file /usr/share/kde4/apps/kssl/ca-bundle.crtplus an ini-file /usr/share/kde4/config/ksslcalist.
See also
  http://websvn.kde.org/branches/KDE/4.1/kdelibs/kio/kssl/kssl/
and
  http://www.roumenpetrov.info/domino_CA/#comment01

It *seems* like replacing the ca-bundle.crt with a symlink to /etc/ssl/certs/ca-certififcates.crt is enough to make KDE recognize the global list of root CAs (at least after a re-login Konqueror doesn't complain about CAcert anymore). So maybe the options stored in the file ksslcalist is obsolete? Got to have a look at the source. Or can anybody with more insight comment?

[Jonathan Thomas (echidnaman)]

Most likely this won't be implemented for KDE 3's kdelibs, since upstream is no longer working on KDE3.

[Malte S. Stretz (mss)]

For some time now I've got this in my root's crontab:

@reboot ln -sf /etc/ssl/certs/ca-certificates.crt /usr/share/kde4/apps/kssl/ca-bundle.crt

Which works fine. It seems (also from grepping through the sources) like the ksslcalist is just some ancient thing from KDE3 and not needed at all (it is horribly outdated anyway).

So replacing the ca-bundle.crt in the packages with a symlink and adding a dependency on ca-certificates should make the whole KDE SSL experience a lot better for Ubuntu.

[Harald Sitter (apachelogger)]

Aye, see bug #334191 SSL support in KDE 4 is broken at a much larger scale than outdated crt file. So this does not qualify as a paper cut at all, more like someone-shot-me-with-a-bazooka-and-I-dont-even-have-use-for-a-medic-anymore ;-)

[Malte S. Stretz (mss)]

Yes, I am a big... umm... fan of KDE bug 162485 :)

Delegating the cert storage to ca-certificates doesn't fix that bug but IMO improves it quite a bit; I can at least add system wide CAs again which make my CAcert servers work. And I haven't noticed any side effects of replacing the ca bundle, so maybe this symlink could just be packaged as part of the KDE packages? (If not, well, the cronjob hack works for me.)

[Jonathan Thomas (echidnaman)]

Hi there!

Thanks for reporting this bug! Your bug seems to be a problem with the KDE program itself, and not with our KDE packages. While we appreciate your issue, it would be better if it was tracked at https://bugs.kde.org, so that the KDE developers can deal with this speedily and have direct communication with you as the reporter for more effective debugging.

Thanks!

[Philipp Kern (pkern)]

While it might be true that it should be reported upstream, ca-certificates is a way specific to Debian/Ubuntu and some others how certificates are handled, so it's distro-specific and should probably tracked there.

[Malte S. Stretz (mss)]

Plus, this bug has a simple hint on how to fix it. A small symlink is enough to improve the current situation a lot.

[rdratlos (rdratlos)]

Even though the proposed fix will/may help to solve the Konqueror issue, it does not fix the Kmail part of [https://bugs.kde.org/show_bug.cgi?id=162485/ KDE bug 162485] (see comment #25). Kmail does not use the certification list that is connected by the symbolic link fix and therefore does not accept the self-signed mail server certificate of my postfix mail server. Maybe the patch that was attached to the bug report here can help but I haven't tried, yet.

Has anyone here tested the patch in KDE4?

[rdratlos (rdratlos)]

After some testing using KDE 4.3 in Kubuntu karmic I can now confirm that Malte's fix works also for kmail. In fact, all kio slaves (like kio_http, kio_smtp) that use the KTcpSocket class correctly support with this fix self-signed certificates.

Kmail correctly uses the certification list that is connected by the symbolic link fix. See extract of the debug log:

kmail(20529) KMComposeWin::doSend: Plain text
kmail(20529) KMComposeWin::doSend: Calling applyChanges()
kmail(20529) KMComposeWin::applyChanges: Entering
kmail(20529) MessageComposer::applyChanges: KMAIL_DEBUG_COMPOSER_CRYPTO = FALSE
kmail(20529) MessageComposer::breakLinesAndApplyCodec: Added an <LF> on the last line
kmail(20529) MessageComposer::breakLinesAndApplyCodec: Added an <LF> on the last line
kmail(20529) MessageComposer::composeMessage: Starting to compose message
kmail(20529) MessageComposer::composeMessage: mEarlyAddAttachments= false mAllAttachmentsAreInBody= false
kmail(20529) MessageComposer::addBodyAndAttachments: Set top level Content-Type from originalContentTypeStr()= "Text/Plain;
  charset="us-ascii""
kmail(20529) KMComposeWin::slotContinueDoSend: true
kmail(20529) KMFolderMaildir::addMsgInternal: FolderStorage::msgStatusChanged
kmail(20529)/kmail (storage internals) KMFolderMaildir::getDwString: KDE_fopen(abs_file= "/home/solkraftwerk/.kde/share/apps/kmail/mail/outbox/cur/1264549308.20529.6aSVn" , "r") == stream == 0x289af80
kmail(20529)/kmail (storage internals) KMFolderMaildir::getDwString: fclose(mIndexStream = 0x289af80 )
kmail(20529)/kdepimlibs (mailtransport) MailTransport::Transport::Transport: "1254495839"
kmail(20529)/kio (Slave) KIO::Slave::createSlave: createSlave "smtp" for KUrl("smtp://<email address hidden>:25/send?headers=0&<email address hidden>&<email address hidden>&hostname=Mark-Aurel.gas.de&size=426")
kmail(20529)/kio (KIOConnection) KIO::ConnectionServer::listenForRemote: Listening on "local:/tmp/ksocket-solkraftwerk/kmailw20529.slave-socket"
klauncher(13962)/kio (KLauncher) KLauncher::requestSlave: KLauncher: launching new slave "kio_smtp" with protocol= "smtp" args= ("smtp", "local:/tmp/ksocket-solkraftwerk/klauncherT13962.slave-socket", "local:/tmp/ksocket-solkraftwerk/kmailw20529.slave-socket")

klauncher(13962)/kio (KLauncher) KLauncher::processRequestReturn: "kio_smtp" (pid 20570) up and running.
kmail(20529)/kdepimlibs (mailtransport) MailTransport::SmtpJob::startSmtpJob: Created new SMTP slave 0x28a4ae0
kmail(20529) KMComposeWin::cleanupAutoSave: deleting autosave file "1264549295.20529.CDuGd"
kmail(20529) KMFolderMaildir::removeFile: Can't delete "/home/solkraftwerk/.kde/share/apps/kmail/autosave/new/1264549295.20529.CDuGd" "No such file or directory"
kio_smtp(20570)/kio (TCPSlaveBase) KIO::TCPSlaveBase::disconnectFromHost:
<b>kio_smtp(20570)/kssl KSslCertificateManagerPrivate::loadDefaultCaCertificates: Loading 155 CA certificates from ("/usr/share/kde4/apps/kssl/ca-bundle.crt") </b>
kio_smtp(20570)/kssl KTcpSocket::showSslErrors: "The host name did not match any of the valid hosts for this certificate"
kio_smtp(20570)/kssl KIO::TCPSlaveBase::startTLSInternal: Cipher info - advertised SSL protocol version 8 n...

[Alex Wauck (awauck)]

The steps needed to mitigate this bug do not seem to have been taken in Lucid. Can we please at least add Malte's workaround for Maverick?

[Harald Sitter (apachelogger)]

This should not be done anyway, unless someone who is involved with KDE's SSL magic agrees with the proposed course of action.

[Tom Helner (duffman)]

Here is another workaround solution that can be leveraged until KDE gets this fixed (https://bugs.kde.org/show_bug.cgi?id=162485), or maybe if they fix it judging by how long the bug report has been open.

My new SSL cert for uses a chained certificate, and was loading with an authenticity check warning because "Entrust.net Certification Authority (2048)" was not included in KDE's ca-bundle.crt. And to add insult to injury KDE no longer has a GUI to import CA Certificates.

Simply appending the Entrust.net_Premium_2048_Secure_Server_CA.crt (already installed from the "ca-certificates" package) to KDE's ca-bundle.crt then restarting KDE fixed this issue for both konqueror and kmail.

$ sudo cp -p /usr/share/kde4/apps/kssl/ca-bundle.crt /usr/share/kde4/apps/kssl/ca-bundle.crt.orig
$ sudo cat /usr/share/ca-certificates/mozilla/Entrust.net_Premium_2048_Secure_Server_CA.crt >> /usr/share/kde4/apps/kssl/ca-bundle.crt
Restart KDE

[Swâmi Petaramesh (swami-petaramesh)]

I finally found out the one and only solution for this bug : After about 10 years of KDE exclusive use and enthusiasm, I shifted to Gnome a couple days ago.

Just fed up with the KDE 4.x branch being a very _nice_ environment graphically speaking but with a whole lot of things broke that worked perfectly in KDE 3.x and have been broke for more than a year now in KDE 4, without any evidence that it will ever be fixed.

The incomplete bluetooth support in KDE and non-working UbuntuOne, and past long pain with KDE Network Manager besides this bug put an end to my patience.

If KDE wants to be a shiny environment with a lot of broken things that used to work but nobody cares, oh well, without me.

If just went to Gnome. I don't like Gnome. It's ugly compared to KDE. But oh well, it works, KDE doesn't, and I just need to get the job done.

[Harald Sitter (apachelogger)]

I just talked to Debian about this and as it stands right now there is little interest of patching in ca-cert support as the KDE upstream is slowly moving towards using platform certs. So instead of deviating from upstream KDE on this they choose to wait for upstream KDE's long-term solution here (which is in general using platform certs). Now short of wanting to deviate from both Debian and KDE, even though both do not appear to consider this a pressing matter, this wish it not worth tracking in a Kubuntu scope as the ultimate resolution would have to be done by KDE.
Hence I am closing it as wontfix for now.

However feel free to reopen this bug once support has landed in either upstream's kdelibs.

[Sander van Grieken (sander-vangrieken)]

Is this bug then triaged into KDE's bug tracker?

If you want to defer it to KDE upstream, please at least provide a link to the upstream bug #

[Harald Sitter (apachelogger)]

I do not know if there is one.

[Sander van Grieken (sander-vangrieken)]

You ARE (one of the) maintainer(s), right?

How are you tracking this issue now, if you don't know if it's in KDE's tracker?

[Harald Sitter (apachelogger)]

There is no issue for me to track. Stuff is working as intended by upstream.

[Sander van Grieken (sander-vangrieken)]

https://bugs.kde.org/show_bug.cgi?id=162485