Bug 144912 - kopete jabber certificate problem
Summary: kopete jabber certificate problem
Status: RESOLVED UNMAINTAINED
Alias: None
Product: kopete
Classification: Applications
Component: Jabber Plugin (show other bugs)
Version: 0.12.3
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Kopete Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-05-01 12:07 UTC by M G Berberich
Modified: 2013-02-27 15:15 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description M G Berberich 2007-05-01 12:07:49 UTC
Version:           0.12.3 (using KDE 3.5.5, Debian Package 4:3.5.5a.dfsg.1-8 (4.0))
Compiler:          Target: i486-linux-gnu
OS:                Linux (i686) release 2.6.21.1-avalon

Connecting to a jabber-server (jabber.fsinf.de) pops up a window that says, that kopete is not able to check the certificate.

Adding the matching cacert.org-certificate to KDEs list of cerificates does not help, probably kopete does not use the KDE-certificates. Having this certificate in openssls certificate-list does not help either.

There is no way to add the certificate to kopete.
Comment 1 Matija Šuklje 2007-05-29 00:15:01 UTC
Same here happens to me (on server gabbler.org) ...but the warning I get says that the certificate is only self-signed (it's a CAcert)
Comment 2 Tim Weber 2007-05-31 07:31:43 UTC
I can confirm that it's apparently not possible to add certificates to Kopete. It would be great if a dev could maybe provide a workaround or simply acknowledge that the problem exists. If that's needed, I could provide him/her with an account on a server with a working CAcert certificate.
Comment 3 Matt Rogers 2007-06-09 07:59:51 UTC
the "problem" is that kopete uses QCA which is not hooked into KDE's certificate stuff. there is no workaround. 
Comment 4 Tim Weber 2007-06-09 19:39:35 UTC
So, if I read http://websvn.kde.org/trunk/kdesupport/qca/certs/ correctly, QCA is using a hardcoded bunch of root certs, with no way to insert others at runtime? That's pretty sad, especially for a protocol like Jabber, where everyone can set up his own server, even without paying VeriSign or whoever.

I know that there's the possibility to check a "no certificate warnings" box, but that is not really an option, because it makes you vulnerable against man-in-the-middle attacks and the like. There's no "permanently accept _this_ certificate" option. I don't know about the QCA API, but wouldn't it at least be possible to add a whitelist of certificate fingerprints somewhere (maybe even manually in kopeterc) and not issue a warning for those?

In the long run, of course, it would be cool if QCA would be able to handle KDE's "certificate stuff" or learn new (root) certificates in any other way.

I'm curious: How do other KDE apps handle SSL/TLS stuff, honouring KDE's central certificate system, and why doesn't Kopete do it that way as well?
Comment 5 S. Burmeister 2007-07-21 14:09:26 UTC
Since Psi uses QCA it should be possible to add new CA-certs, since it does work in Psi. This is really a serious issue since it makes the user ignore SSL-warnings because one is annoyed by false alarms and gets used to just clicking ok.
Comment 6 Justin Karneges 2007-08-03 10:52:46 UTC
QCA is extremely flexible with regards to the root certificates.  Even QCA v1 was this way (and indeed, you could add certs into Psi 0.10 and all prior releases based on QCA v1, dating back to 2003).

With QCA v2, there is additionally a notion of "system" root certificates, which gives you easy access to the root certificate storage of your operating system.  If your OS does not support its own root certificates, then QCA bundles a copy of the Mozilla roots for the occasion (this is what you found in the qca/certs/ dir in SVN).  It is also possible to add alternative system certificate storage support via plugins.  Please note that using the system roots requires a voluntary call to QCA::systemStore().  You are totally in control of what certs count as root certs, and you can even read from your own files and build your own list at runtime, etc, just like with QCA v1.

So yeah, Kopete could do this.  It just doesn't.

I had to write this because the comments on this bug were horrifying. :)
Comment 7 michael perigard 2008-01-20 02:35:25 UTC
*** This bug has been confirmed by popular vote. ***
Comment 8 Alec Kloss 2008-05-16 16:36:16 UTC
In kopete 0.12, this can't be done.  The pertinent bit of code is in kopete/protocols/jabber/jabberclient.cpp:

        QPtrList<QCA::Cert> certStore;
        d->jabberTLS->setCertificateStore ( certStore );

Yes, that's an empty certificate store list.  I've hacked around in QCA-TLS to get it to add the certificates in $OPENSSL/certs and I've also hacked around in kopete to get it to add the certificates from KDE's certificate store.  There's also a bug where Kopete then tries to validiate the server certificate against the IM domain rather than the server hostname.  This keeps it from working correctly for at least talk.google.com.  I've got an awfulhack which fixes this too, but it requires changing a private mHost to public and blindly upcasting from XMPP::Connector to a JabberConnector... yikes.  Would a kopete developer like patches?
Comment 9 Dominik Tritscher 2008-07-22 11:58:47 UTC
I'm using kopete 0.50.80 from Kubuntu packages and can't reproduce that bug here.
Comment 10 Roman Jarosz 2010-01-17 15:40:38 UTC
Please update to newer version as we don't have manpower to support Kopete in
KDE 3. If you still see this bug in new version please reopen this bug report.
Comment 11 Alex Pacini 2013-02-27 15:15:47 UTC
Hi,
I found some the same certificate problems in the last Kopete.
When I connect to talk.google.com kopete says that the certificate is invalid.
I I click cancel and i try to connect again, everything works.
The fact is that it doesn't even show the certificates details and i don't know how to save the certificate locally for a successive check.
Regards