[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [kio] [Bug 162485] KDE 4 SSL Certificate support incomplete
From:       Bernd Paysan <bugzilla_noreply () kde ! org>
Date:       2018-09-26 23:14:00
Message-ID: bug-162485-17878-FO1T3SxjXO () http ! bugs ! kde ! org/
[Download RAW message or body]

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

--- Comment #91 from Bernd Paysan <bernd.paysan@gmx.de> ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.=
[prev in list] [next in list] [prev in thread] [next in thread]