rekonq doesn't trust this site (a bank), while it works fine. The problem seems to be that rekonq says that the root certificate isn't signed by a trusted resource ...(?) This seems to be an extended ssl certificate, which may be the problem?
It works in firefox however and I believe that the skype-site has the same problem.
Thank you for this nice browser. Kind regards,
Steps to Reproduce:
1. Go to site
2. See certificate-warning-message
3. Open in firefox. No problem.
See the site as a trusted site.
Here is other site that Rekonq shows as not trusted:
Rekonq shows the wrong certificate digests. I have exported the certificate with rekonq and firefox to show the difference.
Created attachment 71480 [details]
Exported certificate with rekonq
Created attachment 71481 [details]
Exported certificate with firefox
Git commit 1304a1a979873a716ad58f7050fe5e927cd9ed5a by Andrea Diamantini.
Committed on 20/06/2012 at 19:21.
Pushed by adjam into branch 'master'.
Just check first certificate dates and errors to state IT is valid
M +6 -6 src/webpage.cpp
I still experience the problem on Chakra with Rekonq 1.0
The problem still exists on version 1.1 in kde 4.9 ... It is a nice browser, but useless because of this certificate-problem.
Everytime I visit a site requiring security, I can't use it, so I just use firefox most of the time ...
Anyway, whatever you changed, it didn't fix it. I hope you'll find the problem.
I assume by now that this is a Chakra-specific problem, since it affects at least the Qt browsers there (Konqueror and Qupzilla) as well and looks like only Chakra users are reporting the problem here.
I have therefore opened a bug in Chakra ( http://www.chakra-linux.org/bugs/index.php?do=details&task_id=473 ), I'd recommend to vote for and comment on it.
I can confirm you that. I have just tested Rekonq 1.0 from Backports on Kubuntu 12.04 and there is no problem more with the certificate checking.
It works here on ArchLinux and people reported it works on kubuntu. So I consider this fixed.
Forgot to say... fixed because before my commit we were really refusing extended certificates. After the reopen, I should say resolved ->downstream.
(In reply to comment #9)
> It works here on ArchLinux and people reported it works on kubuntu. So I
> consider this fixed.
I can reproduce the exact same issue on Arch and Chakra (all 3 sites linked on the Chakra bug report show none of the certificates are trusted in Arch either), what qtwebkit version are you using? Qt version from the Arch repo's or custom build?
I'm using qtwebkit from Arch repository, of course. Otherwise, I would not state it working on Arch linux here ;)
(In reply to comment #12)
> I'm using qtwebkit from Arch repository, of course. Otherwise, I would not
> state it working on Arch linux here ;)
Should I open a bug report in Arch then? Since with all repository packages from Arch, none of the mentioned site work. No idea how you get them to work on Arch.
(In reply to comment #13)
> (In reply to comment #12)
> > I'm using qtwebkit from Arch repository, of course. Otherwise, I would not
> > state it working on Arch linux here ;)
> Should I open a bug report in Arch then? Since with all repository packages
> from Arch, none of the mentioned site work. No idea how you get them to
> work on Arch.
Not sure now where the fix is tested, bug is still present in Chakra, Arch, and Kubuntu (latest ISO, rekonq 1.1
well... I read bug report in chakra it seems I let it work, while given the bugfix it JUST works here. To get sure about what I'm saying I downloaded myself last kubuntu DVD and installed it in virtualbox.
In my test there rekonq works as expected.
In the screenshot attached, you can see rekonq 1.1 on kubuntu && rekonq 1.80 (will be released tomorrow) on arch working on the site.
I can ensure they share the same code SSL related. In fact the commit in this bug was my last one in the SSL area.
On the other hand, I saw in kubuntu the kio widget saying the certificate is not trusted (would you like to trust it forever/for the current session ??), while on load finished rekonq correctly recognizes the certificate. The kio problem is beyond my bunch of code and cannot probably be fixed until kde 5.
Created attachment 75527 [details]
rekonq working on kbc.be on arch & virtual kubuntu
The whole point for the bug report imo is the need to accept the untrusted site. There is no issue in any distro to get to any of these banking sites by clicking through the untrusted warnings.
Hm so you mean the certificate warning which occurs when loading a page in rekonq does not come from rekonq itself, but from KIO? Why is there a KIO warning when loading a page in a browser?
Abveritas is correct: The issue of this bug is not that the pages cannot be loaded at all, but that there is a certificate warning even though the certificate is actually correct (the same pages load without a warning in Firefox).
well.. what you stated in the last 2 comments is obvious. In fact rekonq, also before this bug report and the related fix, was loading the sites without problems.
What I'd like to let you note is that AFTER the bug fix, when one of the sites reported here is loaded, rekonq shows a green bar (it basically means SSL ok) and clicking on the usual lock (ssl) icon reports the correct certificates showing they are correctly trusted.
The message window shown during site load in some of them comes from kio. It has nothing to do with rekonq, but I cannot disable it in any way (at least in kdelibs4). Yes, I can remove it stopping using kio :)
This also means it will be shown with every app using kio browsing an https site with "extended" certificate (rekonq, konqueror/khtml, konqueror/webkit, etc.) but NOT qupzilla, using plain qt network. if it doesn't work there they have a separate and different bug.
Since this bug is exactly the same for any Qt browser (including konqueror using KHTML or webkit, qtestbrowser and qupzilla), seems to me this is a bug in Qt.
I just stumbled on the same bug in KMyMoney 4.6.3, KDE 4.9.3, with libofx 0.9.5, under Gentoo Linux, when trying to fetch transactions via OFX-direct-connect. To me, that shows it is not browser related at all, but beyond that, I can't tell whether it's qt, ssl, kio, .... However, something is clearly wrong.
there is the same issue in opensuse 12.2 64 bit.
konqueror and rekonq
KDE / konqueror 4.9.3
I filed a bug in Kio here: https://bugs.kde.org/show_bug.cgi?id=312550