Bug 162485

Created attachment 24896 [details]
authenticity check mentioning kde control center

Created attachment 24897 [details]
Accepted Import

Created attachment 24898 [details]
Certificate details

Created attachment 24899 [details]
Chain Details

Created attachment 24900 [details]
Chain Details Again

Created attachment 24901 [details]
Crypto Manager Dummy Data 1

Created attachment 24902 [details]
Crypto Manager Dummy Data 2

Created attachment 24903 [details]
Crypto Manager Blank Signers

Created attachment 24904 [details]
Crypto Manager Import Complete

I actually don't know if this belongs to Kssl or Konqueror.  Please assign appropriately.

same for 4.1 beta1

I can confirm this bug, all EV certificates I have tried from Comodo don't work in KDE 4.0.4 and 4.1 beta 1 while they work without problems in previous KDE versions and on Firefox and Internet Explorer.

As Comodo is one of the major SSL providers I think this is an important bug to fix.

still doesn't works in 4.1

There are two issues here:

1) KTcpSocket (the underlying socket implementation) is using Qt's bundle of CA certificates, instead of loading KDE's bundle.

2) QSslCertificate is quite strict and doesn't accept extra whitespace at the end of the certificate declaration in PEM mode. Both KDE's and Qt's own bundles contain certificates with those extra whitespace.

Created attachment 25457 [details]
Proposed fix.

Pavel is working on a build with this proposed fix, and I'll test later tonight.

Created attachment 25458 [details]
New version of the proposed fix

Thanks to Pino Toscano for pointing out that I checked hasMainComponent twice.

Tested with the second patch.

The Komodo chained certificates are now trusted, and visiting a site with a self-signed or untrusted certificate shows details for the certificate being used (except for the text TODO in the "trusted" field of the details dialog).

However, Certificates imported through the "Configure Konqueror"->"Crypto"->"SSL Signers" interface do not stay imported.  A test certificate is linked above, or attempt to import the CACert.org root certificate.

I am still unable to load SSL Signer certificates in a build of tagged 4.1 RC1.

I see this bug as well on KDE 4.1 / Fedora9 (kdebase-4.1.1-1.fc9.i386).
IMHO this is a major blocker bug!

*** This bug has been confirmed by popular vote. ***

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

Guess we all agree that this is a major bug.  Will try to test the patch when I've got some time.

I have the same problem here (KDE 4.1.2 from kubuntu 8.10).
This bug seems to induced another very annoying thing: in kmail, I cannot send emails using a server that asks for my certificates (the certificates are never send).
Thank you in advance for your time!

Same, this bugs severely affects me on KDE 4.1 from Kubuntu 8.10. Same as Emmanuel above, I cannot send email using KMail anymore as my server cert cannot be imported into KDE, and my personnal cert cannot either, where my SMTP server requires KMail to provide the certificate.

Solving this bug is of extremely high priority to me, and I cannot really understand how KDE 4.1 could be released as "stable" with certs management not finished (KDE crypto config module displays a dummy "ACME Frauds Department" cert in my name, and no CA certs at all, IMHO it shows the code is simply not finished).

Many thanks in advance for your help in solving this.

As you're using Kubuntu, you might be interested in this bug:
  https://bugs.launchpad.net/kdelibs/+bug/295266

It won't fix KDE's cert handling but makes the global ca-certificates available to KDE; just do a
  sudo ln -sf /etc/ssl/certs/ca-certificates.crt /usr/share/kde4/apps/kssl/ca-bundle.crt
and you'll have at least CAcert and stuff recognized in KDE.

Ah, thanks, Malte. It did the trick in FreeBSD too :)

# cat my-cacert.pem  >> /usr/local/kde4/share/apps/kssl/ca-bundle.crt

Are you planning to support SSL? Currently can't really use any online application which requires a working SSL. Konqueror is not usable.

Ye really, this bug is open since may 2008. The use of SSL these days is very important and Konqueror does not even support it. One of the reason I keep falling back to firefox ... because it works.

I can actually hardly believe that such a regression has been signaled for 8 months - KDE 3.x was managing SSL certs well, the feature is simply not complete and not working at all in KDE 4.1, and nothing seems to have been done in 8 months for fixing this...

We're not talking about a small issue with GUI flashy widgets or icons or the like, we're talking about SSL support KDE-wide, in Konqueror but in KMail as well. It's completely broke in the KDE 4 branch and the developpers team doesn't seem to take the issue seriously and make this a priority.

I would certainly not have "upgraded" from the well working KDE 3.x to KDE 4.1 should I have known SSL certs support was plain dead, but seing it still is 8 months after it got reported simply questions my confidence about the whole KDE project.

Indeed, this is the main reason I didn't upgrade the KDE 3.5 on my notebook to KDE 4 yet.

I had a look into the SSL code and it seems like it was "ported" without much change from KDE 3 and before that from KDE 2 and maybe KDE 1 or whatever.  Its quite a messy piece of code and I guess nobody really understands what it does now that George Staikos isn't around for maintaining it anymore (or is he?).

From what it looked to me it seems like the whole stuff should be rewritten and KDE 4 is in dire need of a new and modern SSL (and TLS) framework, more or less like what Phonon and Plasma and Akonadi brought.  But unfortunately it also seems like nobody is interested in that non-flashy, but important part of the KDE infrastructure.

As obviously nobody is really interested in the dull task of creating a modern SSL framework for KDE in his/her sparetime, maybe Novell or somebody else could sponsor a developer to do it for money.

> As obviously nobody is really interested in the dull task of creating a modern
> SSL framework for KDE in his/her sparetime, maybe Novell or somebody else could
> sponsor a developer to do it for money.

If you know a developer who can make this, my company is willing to sponsor him.

I don't believe KSSL is used in kio_http anymore, but rather Qt's SSL code. 

Whatever SSL library is used we want fully usable SSL support with certificates import export etc.

There's a lot of wonkiness in Konqueror 4.2.0's SSL support. For example, I'm hitting this page via https, and I didn't get any warnings about invalid certificates, but when I go in and check the certificate (by clicking on the little green shield in the top right), it says that the SSL certificate for *.kde.org doesn't apply to this domain (bugs.kde.org), which is obviously incorrect.

It's not just an issue with wildcard SSL certificates as I initially thought, either. I went to https://www.verisign.com, and the dialog says the same thing (again with no warning), but their certificate is for www.verisign.com, no wildcard.

Furthermore, I hit https://localhost/ (which has an expired and self signed SSL certificate), for which I get a warning, but then after clicking through the warning, I have no indication at all that I'm viewing a site with an invalid SSL certificate (the green shield is the same as before, etc).

Which leads me to notice that there's barely any indication of whether or not SSL is in use for the current site. There's the tiny green shield in the top right, and there's an s at the end of http, but that's it. There's no padlock (locked or otherwise) anywhere and there's no yellow background on the URL bar, both of which Konqueror 3.5.x did.

Why has this not been fixed yet? SSL is a very critical feature and I've been observing this problem from 4.0.0 until now.
I am still unable to import any custom CA into konqueror (without hacks).

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

Will it be fixed in KDE 4.3?

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

Isn't Bug 185288 also a duplicate?

I think that Bug 185288 is a duplicate, though is narrower in scope.  Looking back, I originally described at least three problems.  Thiago provided a patch to fix chained certificate viewing, which was much appreciated, but did nothing to address being unable to import a certificate authority (signer ssl certificate), or view certificate details (signer or otherwise) when connecting to an SSL or TLS service.

Today I noticed that kleopatra, while it CAN import a root CA, cannot allow the user to mark it trusted.  Also, it is capable of displaying certificate details appropriately.

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

There still seems to be no progress at all (KDE 4.3.3 - fails as well) - the only major "breakthrough" was to remove the dummy certificate manager part of Konqueror's configuration. No developer posting grumpy messages like "I have more important things to do" and "nobody needs SSL anyways" or so, so I think this part is completely abandoned and looking desperately for a developer. It's not only that KDE can't manage certificates, SSL transfers abort with timeouts without any reason (the timeout message appers so quickly that there can't have been a timeout), making even the usual login through a SSL redirect difficult (you have to resend several times until it gets through).

For anyone using SSL/TLS for serious internet security, this is a complete show-stopper.

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

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

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

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

I exchanged some information about this severe bug with several key kde
people.  Here is a summary of things that have been said:              

> I started to search the kde's bug system for this problem, because going to
> this website http://mijn.ing.nl/ (a big Dutch bank) pops up a window with  
> the message that the certificate can not be verified.  At the same time,   
> there is no way (AFAIK) to verify / look up which certificates or          
> authorities are trusted.                                                   

Ah, I see. The UI is missing.

That website is popping up as error here too. It comes from OpenSSL, which is 
reporting that it couldn't establish the trust path. It may be that we're     
missing some root certificates in our bundle.                                 


> When you would use https://mijn.ing.nl/ the request is redirected to
> https://mijn.ing.nl/internetbankieren/SesamLoginServlet, no pop up window
> is shown.  But there is now no way to verify the (bank) certificates.    
>                                                                          
> > Konqueror offers minimal SSL support. This has been working since KDE  
> > 2.1, or now 9 years.                                                   
>                                                                          
> But konqueror has become better, and can now be used on more sites.  I just
> tried the same site with kde3-konqueror and that one provides the (minimal)
> functionality that one would expect from a browser, including the          
> possibility to verify certificates and authorities (konqueror -> settings  
> -> cryptography).                                                          

Yeah, that UI is missing, but the functionality is the same.


> > Konqueror doesn't offer E.V. support. That's not part of "minimal". It
> >  probably needs API in Qt, but I also have no idea what is missing.   
>                                                                         
> I don't know what E.V. support means.  At the moment the cryptography   
>  settings are missing in my version of kde4-konqueror (openSUSE-11.1    
>  kde-4.3.4).                                                            

Extended Validation.


> I hope that this information makes the problem clearer.

Yes. It means there's nothing I can do, because the problem is UI.


> Well, AFAIK the UI was removed because the API for it didn't exist
>  anymore...

Managing the certificate store doesn't require an API. It's a simple file or set
of files, each containing a certficate that QSslCertificate can read.

Setting trust relationships as well as distinguishing root CAs from personal
certificates from stored remote certificates is something done exclusively in
KDE code. No need for API in Qt.
-------

This is it for now.  I hope it is usefull for someone.

If a new GUI is going to be added, it would be nice to display the most basic certificate information only, and hide the details in a tab.  As can be seen on this webpage http://www.davidpashley.com/articles/cert-authority.html in the section about Internet Explorer (look for the phrase "You'll be shown information about the certificate").

While new versions are released without SSL support, I'm switching to something reliable and removing myself from this coulda-woulda-shoulda chat.

I cannot understand why you dare to call KDE 4 "stable" with such a basic thing missing.

(In reply to comment #18)
> Tested with the second patch.
> 
> The Komodo chained certificates are now trusted, and visiting a site with a self-signed or untrusted certificate shows details for the certificate being used (except for the text TODO in the "trusted" field of the details dialog).
> 
I checked the source code of KDE 4.3 and did some debugging. The mechanism that is proposed by the (second) patch is now part of the KTcpSocket class source code. As KtcpSocket is used by all main kio slaves (i. e. kio_http, kio_smtp) applications like Konqueror, KMail and others are SSL capable again in KDE 4.3.  

Background:
The KTcpSocket class uses a central certificate list in directory /usr/share/kde4/apps/kssl/ca-bundle.crt. The user can also specify an own list in ~/.kde/share/apps/kssl which will be loaded in addition to the central list.

rdratlos, is there something similar for specifying which *client* certificates to use when connecting to particular servers?

(In reply to comment #26)
> It won't fix KDE's cert handling but makes the global ca-certificates available
> to KDE; just do a
>   sudo ln -sf /etc/ssl/certs/ca-certificates.crt
> /usr/share/kde4/apps/kssl/ca-bundle.crt
> and you'll have at least CAcert and stuff recognized in KDE.

As long as there is no working central KDE certificate management you have to rely on the certification capabilities of your distribution or of central bodies like mozilla. What you need at least is a certificate list that can be imported by KtcpSocket (see comment above). 

This can be achieved by using a (root) certificate list from your distributor (e. g. with package ca-certificates in Ubuntu) or by creating such a list from e. g. Mozilla's repository (see e. g. http://www.issociate.de/board/post/170599/updating_ca-bundle.crt.html). Once you have that list put it into /etc/ssel/certs and link it as proposed in comment #26.

If you have self-signed certificates in your network you have to add your root certificate to the certificate list in order to KTcpSocket let accept the self-signed server certificate:

$ sudo su
# sudo cp /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/ca-certificates.crt.bak
# cat myRootCertificate.pem >> /etc/ssl/certs/ca-certificates.crt

Have you actually tried that? I've added the cacert root certificate to /etc/ssl/certs but I still have to accept my server certificate if I go to: https://milliways.cynapses.org/

The next thing is that I have to accept the certificate every time I connect to my server, even if I click on accept forever. This doesn't look like a working SSL infrastructure to me.

(In reply to comment #54)
> Have you actually tried that? I've added the cacert root certificate to
> /etc/ssl/certs but I still have to accept my server certificate if I go to:
> https://milliways.cynapses.org/
> 
> The next thing is that I have to accept the certificate every time I connect to
> my server, even if I click on accept forever. This doesn't look like a working
> SSL infrastructure to me.

by the way (very related), the default kde webbrowser for kde 4 in opensuse is firefox.
'nuff said.

(In reply to comment #52)
> rdratlos, is there something similar for specifying which *client* certificates
> to use when connecting to particular servers?

It depends on the KDE app and the kio slave it uses. In general, the tcpslave supports also client certificates using kssl. Kssl itself provides the means to manage client certificates. So your application must use the relevant APIs. A central management (including a central list) is not required.

(In reply to comment #54)
> Have you actually tried that? I've added the cacert root certificate to
> /etc/ssl/certs but I still have to accept my server certificate if I go to:
> https://milliways.cynapses.org/
> 
> The next thing is that I have to accept the certificate every time I connect to
> my server, even if I click on accept forever. This doesn't look like a working
> SSL infrastructure to me.

The location of your bundle is wrong; kde has to use its own bundle (WHY?).  On Kubuntu it's in /usr/share/kde4/apps/kssl/ca-bundle.crt.  See this blog post for more information: https://www.dragonstrider.com/serendipity/index.php?/archives/352-Working-around-KDE-bug-162485.html

The workaround from comment #57 fixes https, but not imap with TLS.

I've been using IMAP with TLS for month with this workaround. Maybe you need to logout to force the ioslave to reread that bundle?

Using 4.3.3 (Kubuntu Karmic), it seems that the "Remember forever" option does
work in both Konq and Kmail.  But I also notice that the SSL infrastructure UI
has been removed completely from the konqueror settings.

This report is a kitchen sink of still valid and fixed bugs.
I would like to close it but somebody would surely reopen it because some of the bugs here are still present. I know. Instead I'll disregard the bug for now and close it later when the most important issues have been fixed. But this report is *not* useful.

For most of the issues there is a separate bug report already, feel free to open new, *specific* ones for remaining issues without a bug number of their own. If a bug that is not a crash can't be described in terms of "I expected A to happen but B happened instead" it is usually not specific enough.
The SSL certificates user interface was removed because it didn't work - that does not mean that I like it that way.

About having a separate certificate bundle in KDE, this decision was made before I took over maintenance of that code and I don't think it is a good idea anymore. I will consult with a few fellow developers to see if we can change that.

(In reply to comment #61)
> This report is a kitchen sink of still valid and fixed bugs.
> I would like to close it [...]
You are reversing a process that apparently tried to merge all SSL related bugreports into this one (e.g. Rex Dieter marking a duplicate in bug #178806 comment #8). Perhaps you should coordinate on which path you want to take. ;)

(In reply to comment #61)

I agree to Andreas. But we need a clear documented proceeding in order to avoid that we have the same mess again because of people reopening this bug.

> This report is a kitchen sink of still valid and fixed bugs.
> I would like to close it but somebody would surely reopen it because some of
> the bugs here are still present. I know. Instead I'll disregard the bug for now
> and close it later when the most important issues have been fixed. But this
> report is *not* useful.
> 
> For most of the issues there is a separate bug report already, feel free to
> open new, *specific* ones for remaining issues without a bug number of their
> own. If a bug that is not a crash can't be described in terms of "I expected A
> to happen but B happened instead" it is usually not specific enough.
> The SSL certificates user interface was removed because it didn't work - that
> does not mean that I like it that way.

We need somebody who makes a list of all sperate bugs on KDE 4.3 with regard to SSL. If we add this list as comment to this bug, people hopefully take care before opening a new one. In addition, some guidance would be helpful, because people usually experience the problem in on eof KDE's applications. But SSL related problems usually come from the underlying KIO framework. Especially in Ubuntu it's so easy to provide a comprehensive debug output using kdebugdialog, which also includes the KIO slaves.

> 
> About having a separate certificate bundle in KDE, this decision was made
> before I took over maintenance of that code and I don't think it is a good idea
> anymore. I will consult with a few fellow developers to see if we can change
> that.

A similar discussion took also place in the Ubuntu bug tracking system. From there it seems that there are two strategies. The one is to have a distribution central certificate management (especially for root certificates) which can be used by all applications. The other one is to have KDE as basic application framework to provide an own certification management for all KDE based applications. As KIO still requires client certificates the work-around proposed here does not solve the problem completely. It's a good idea to discuss that with development people and include the outcome of the discussion here as a comment. 

After that it's really the best to mark set up the missing bugs/wishes and close this bug as duplicate. I see good chances that in this way we clean-up the mess here.

I don't agree to close this bug as dup.  A lot of people voted for this bug
report and therefor it is there in the top 3 of most voted bug report.
This bug report has now 1287, number 2: 1566 and number 4: 1123!

If this bug is close all those votes would be lost.  Having so many votes makes this bug report visible and it gives the possibility to "escalate" (although the later is not really possible in a volunteer group like KDE).

Splitting this bug up in more pieces is part of the process of fixing it. You'd rather vote for a bug than have people work on it?

Remember, BKO is primarily a tool to help developers track defects, not hitlist of favourite bugs. The bugreport as such is not useful anymore, as it mixes up several issues. Splitting it up makes it easier to identify the separate issues and fix them one for one, really the only way to do something about it.

Don't get too hung up on votes on bugs, not every developer cares about them. In this case, the severity is clear enough, so we don't actually need those votes.

(In reply to comment #64)
> I don't agree to close this bug as dup.  A lot of people voted for this bug
> report and therefor it is there in the top 3 of most voted bug report.
> This bug report has now 1287, number 2: 1566 and number 4: 1123!
> 
> If this bug is close all those votes would be lost.  Having so many votes makes
> this bug report visible and it gives the possibility to "escalate" (although
> the later is not really possible in a volunteer group like KDE).

I'd like to propose a pragmatic alternative to the splitting/keeping discussion. The number of votes points to that the SSL subsystem has considerable flaws.

Single bug reports are useful if the problems reported here can be tracked to limited code fragments where the bugs can be fix. But in case of a more general problem (as it looks like here), we should keep the bug open for the time being.

Instead, my proposal is to open e.g. a subpage on TechBase to collect information in a structured way. Such an analysis is more useful than a number of bug reports distributed in a bug database, mixed with off-topic comments or unrelated bug descriptions.

Once the issues have been sorted and clearly structured, the best way to solve them can be determined. Either by performing a number of smaller fixes or a major rewrite of the code. Maybe someone who is familiar with the problem and (hopefully) the code can step up and do the structuring part...

I'll try a list of things that don't work:

* Certificate management missing: The only way to add root CAs is by modifying the text file /usr/share/kde4/apps/kssl/ca-bundle.crt by hand (and this is especially annoying when you, like me, check out and test new KDE releases frequently). Solution: Look at KDE 3.5.10 for certificate management. The user shall have the ability to import certificates, to trust particular site-certificates "forever" or "for session", and inspect them in a certificate manager where he can add/delete or change status of certificates.

* Konqueror gives false sense of security by showing a green checkmarked shield when the check actually failed through a missing root CA (for class 3 certificates, where the root CA is actually part of the certificate, but can't be trusted). The same is true for other kssl clients like kmail, which also silently accept such a certificate without warning and without any way to inspect the validity of the certificate. There shall be a way to inspect all kssl connections active or recently used (e.g. by having a kssl icon in the tray bar).

* Client certificate management missing: There is no way to use a client certificate for client authentication through kssl. Again, look at KDE 3.5.10 for client certificate management, and how to deal with it. The user must have the ability to import his client certificates - or use Kleopatra as client certificate manager. He also shall be prompted with a client certificate request dialog when such a request comes from a SSL connection - and then should be given the option to "send selected certificate", "don't send a certificate", and chose to remember this setting for the specific site or all sites forever/per session (especially if he doesn't have or wants a client certificate, choosing "never, ever" to avoid annoyances is important). He shall be able to review all those choices as usual (client certificates are cryptographically strong cookies, so treat them as similar to cookies as possible).

I found the certificate management as part of Konqueror config slightly konfusing in KDE 3.5.10, I'd rather suggest that this is a separate entity, e.g. throught the suggested kssl icon in the tray. kssl is used by more programs than just Konqueror.

Bernd Paysan gave perfect overview - if you want to see how things should work - look at kde 3.5.10. And I second the opinion that it maybe extracted to separete entity as SSL is used not only in konqueror.

Another important thing that's missing, and has also been missing from previous versions, is support for Certificate Revocation Lists.

Bernd et al, how about creating one bug report for each of these and let this bug depend/block on these if thats possible? Can anyone with enough bugzilla karma / knowledge give a direction on how to proceed? I think one bug report per issue helps defining concrete next steps that need to be done.

(In reply to comment #70)
> Bernd et al, how about creating one bug report for each of these and let this
> bug depend/block on these if thats possible?
May I advise you to first search for existing bug reports on those issues?
E.g. there is bug #178806 which already covers the client certificate issue.

Bug still present in KDE 4.4.2 I have free comodo smime certificate for e-mail signing and encryption. The e-mail signature does not work in KDE4. However in KDE3 worked perfect. Without e-mail signature possibility KMail in KDE4 sucks.
I have to use Thunderbird to send signed mails.

(In reply to comment #72)
> Bug still present in KDE 4.4.2 I have free comodo smime certificate for e-mail
> signing and encryption. The e-mail signature does not work in KDE4. However in
> KDE3 worked perfect. Without e-mail signature possibility KMail in KDE4 sucks.
> I have to use Thunderbird to send signed mails.

I don't understand.  I use KMail 1.13.2 (KDE 4.4.2), and I sign and encrypt S/MIME emails every day, as well as decrypting emails sent to me and validating signatures.  It all works fine, but that's because KMail uses GPGSM for all its crypto operations, not the SSL support (or lack thereof) in kdelibs.

(In reply to comment #73)
> (In reply to comment #72)
> > Bug still present in KDE 4.4.2 I have free comodo smime certificate for e-mail
> > signing and encryption. The e-mail signature does not work in KDE4. However in
> > KDE3 worked perfect. Without e-mail signature possibility KMail in KDE4 sucks.
> > I have to use Thunderbird to send signed mails.
> 
> I don't understand.  I use KMail 1.13.2 (KDE 4.4.2), and I sign and encrypt
> S/MIME emails every day, as well as decrypting emails sent to me and validating
> signatures.  It all works fine, but that's because KMail uses GPGSM for all its
> crypto operations, not the SSL support (or lack thereof) in kdelibs.

With help of some tutorials on the net I also made my certificate working with KMail. But this is quite hard to do. You need to create/modify the files in $HOME/.gnupg: dirmngr.conf  dirmngr_ldapservers.conf  gpg-agent.conf  gpg.conf  gpgsm.conf  scdaemon.conf Then write 2 scripts: gpg-agent.sh in .kde/env and shutdown which start and stop gpg-agent with kde. Then using gpgsm --import load your certificates to keyring. If it does not ask for password saying 'pinentry timeout' it will fail. I do not know how I managed to make this pinentry working but suddenly during yet another try and playing with gnupg configs pinentry showed up in text mode and asked for password 3 times. This time private certificate was imported and works in KMail.

Comparing how much tricky things with gpgsm have to be done with how easy was to import certificate to Thunderbird I must say KMail needs much improvement in this area.

(In reply to comment #74)

1.) KDE on Gentoo already comes with scripts /etc/kde/startup/agent-startup.sh and /etc/kde/shutdown/agent-shutdown.sh.  You only need to uncomment the lines for gpg-agent in those scripts.

2.) You can configure the GPGSM backend through KMail by choosing "Configure KMail" from the "Settings" menu, going to the "Crypto Backends" tab on the "Security" page, selecting "S/MIME (gpgsm)", and clicking "Configure".  There should be no need to manually edit GPGSM's configuration files.

3.) Emerge kde-base/kleopatra.  Then choose "Certificate Manager" from the "Tools" menu in KMail.  That will launch Kleopatra, where you can import your certificates and private keys using a fairly intuitive GUI.  There should be no need to invoke gpgsm from a command line.

This bug is still present in KDE 4.5.1, and to make matters worse, it appears that the workaround doesn't work anymore.  It just says that the certificate cannot be verified due to "internal reasons".

Still present in debian experimental kde 4.6.2. 
How could that be? I cannot use webmin for my remote servers with konqueror because with every click I am asked again if i want to accept the self signed certificates.

The lacking and IMPORTANT feature of SSL Certificate management renders konqueror useless for certain tasks.

also still existant in KDE 4.6.3. I believe the KDE team's stance on this serious bug is "if you need it code it yourself. it's open source after all."

KDE 4.8.3, still no real changes here.
Konqueror is still unusable as a web browser as soon as somewhat more serious SSL is involved.

KDE 4.9.5, still not working, and this bug is in "needsinfo" since idunnohowlong.

What is needed here?

What I've run into recently is that it fails to work with SSL client
certificates.

On Thu, Jan 17, 2013 at 06:02:12PM +0000, Mathias Homann wrote:
> https://bugs.kde.org/show_bug.cgi?id=162485
> 
> --- Comment #80 from Mathias Homann <Mathias.Homann@opensuse.org> ---
> KDE 4.9.5, still not working, and this bug is in "needsinfo" since
> idunnohowlong.
> 
> What is needed here?
> 
> -- 
> You are receiving this mail because:
> You voted for the bug.

I think what is needed here is a guy who knows what SSL is and how it works.  And who takes the time to implement it.  I feel like talking with some indian outsourcer here, whom you tell "You have not implemented the SSL protocol, only a subset", and the answer is a parrot saying "I need more info, I need more info".

Here's more info:

http://tools.ietf.org/html/rfc6101

That's the latest RFC on TLS; you will best use OpenSSL to implement it, which does most of the stuff for you:

http://www.openssl.org/docs/ssl/ssl.html

So, I think that's enough of information: The SSL/TLS implementation in KDE 4 implements only a small subset.  It needs some serious effort to get it usable.  KDE 3's SSL support was complete and worked.  However, that guy apparently left, and the rest of the KDE team can only do flashy GUI stuff.  This is not flashy GUI stuff, this is serious cryptography stuff.  Therefore, nobody cares.

The deficiencies in KDE4 have a lot more to do with X.509 than with SSL/TLS. The protocol implementation is fairly complete. What is lacking is a way of managing the available X.509 principals, trust settings, validation settings for the trust engine (e.g., CRL, OCSP), client certificate authentication settings for KIO, and so forth.

I know this is old, but this is still an issue with KDE 4.12.3 (Fedora 20). 
* I go into the SSL Preferences of the System Settings
* Click Add... 
* Select a .der CA certificate. The dialog goes away and the certificate is not listed in the SSL Signers. It just silently fails. 

Being able to add trusted CA certs is important, particularly in enterprises.

Rick: Please open a new bug for this and add it here to the Depends: list.

Andreas - this appears to be working.  I'm not sure if it's the newer version of KDE I'm using (4.13.3) or the fact that it's installing them under User-added certificates all the way at the bottom of the list and I never noticed that before.  So, they are being added, however, I would suggest adding some sort of feedback to the user that they were added.  Perhaps a dialog showing that it added n certificates and show their name or display that in a status-bar like message.

(In reply to Rick Alther from comment #84)
> I know this is old, but this is still an issue with KDE 4.12.3 (Fedora 20). 
> * I go into the SSL Preferences of the System Settings
> * Click Add... 
> * Select a .der CA certificate. The dialog goes away and the certificate is
> not listed in the SSL Signers. It just silently fails. 
The situation is still the same (tested on openSUSE Tumbleweed 20160625). I use KDE Plasma 5.6.4 and KDE Frameworks 5.23.0.

systemsettings (KDE 4, package kdebase4-workspace-addons) has a SSL configuration, but it does not add the Cacert.org root certificates (https://wiki.cacert.org/FAQ/ImportRootCert#KDE). systemsettings5 has no SSL section.

> Being able to add trusted CA certs is important, particularly in enterprises.
Yes, I agree. Strong authentication (e.g. with SSL client certificates and smart cards) becomes more and more important.

Even if it is unrelated to that bug: for OpenSUSE you have the possibility to just install the package ca-certificates-cacert and have it in the system store without further work.

(In reply to Rolf Eike Beer from comment #88)
> Even if it is unrelated to that bug: for OpenSUSE you have the possibility
> to just install the package ca-certificates-cacert and have it in the system
> store without further work.

Yes, thanks. I already have this package installed.

Your tip can be seen as a general work-around for incomplete SSL support in KDE. Root certificates can be always installed system-wide.

Personally I am currently more interested in importing my SSL client certificate, so that KDE applications like Dolphin, Konqueror or Dolphin can use it for authentication purposes. Here I don't see a possibility to do this system-wide and in KDE it's not possible. This problem matches the title of this bug, but not the description. See #319049.

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

What info is needed?

There has been some progress, both in what Konqueror can do, and about what's now considered good practice, so the situation is not the same as in 2008 anymore.

If you want to check whether server certificate work, go through https://badssl.com, that is a full test suite for everything around ssl certificates and some more.  All green links shall work, all red links shall error. There needs to be a way to deal with client certificates (also tested; badssl.com provides two certificates, a good and a bad one to check success and failure). There are still several cases on badssl.com where Konqueror misbehaves, but it's not that awful. pinning-test is something that is phased out (i.e. even Chromium accepts the pinning-test site).

I've succeeded to add my own untrustworthy CA (one of my own test cases) permanently (which is good), but didn't find a way to get rid of it again (which is not so good), though I rm'd the ksslcertificatemanager file in ~/.config, which contained said certificate. Maybe I just need to log out and log in again to make that effective.

My CA has the usual three-stage process, so there's a root, an intermediate, and an actual server certificate.  After allowing that certificate “permanently”, the root still was untrusted (ok), the intermediate was trusted (not so good), and as a consequence the server certificate is trusted.

The “trust certificate permanently” should only trust the certificate itself, otherwise KDE should provide an option to select which certificate in the chain should be trusted permanently.  It also should be possible later to remove such trust of user-imported certificates.  And the certificate box should state that the trust has been overridden by the user's own import.

I don't know, I didn't set the NEEDSINFO status. This was just an automated reminder. I'll mark it REPORTED for now.

*** This bug has been confirmed by popular vote. ***

This bug is so old, and so piled on, it's not useful any more and could never be closed as fixed. New bugs should be filed for modern versions of KDE/Plasma and individual apps that are missing specific expected SSL/TLS/PKI features. One issue per bug report.