Version: (using KDE 4.4.2) OS: Linux Installed from: Ubuntu Packages After I have updated from Ubuntu 9.10 to 10.04 beta, kontact asks on each start whether I trust the self signed ssl certificate of the two imap servers I have configured. (ugs.tarent.de and pcornelissen.de) It stores this trustlevel (I always say "trust forever") not permamently, because when I restart kontact it asks again. (Which is not "forever" in my opinion) ;-) BTW It worked fine in ubuntu 9.10 which uses version 4.3.5 I had some problems with kontact before so my .kde directory has been deleted and kontact 4.4.2 was able to set everything on it's own without converting.
FYI: I have created a bug at launchpad first (see URL field)
(In reply to comment #1) > FYI: I have created a bug at launchpad first (see URL field) grml... looks like the content of the URL field has not been saved... So here it is: https://bugs.launchpad.net/ubuntu/+source/kdepim/+bug/557353
OK, the trustlevel isn't even saved during the "uptime" of kontact. I'm asked again for the same server+certificate frequently over the day.
Likely duplicate of 114797 and 116723 ... I hit this very same bug today on kontact 4.4.7 running on KDE 4.5.3. -sigh-
*** Bug 264275 has been marked as a duplicate of this bug. ***
*** Bug 259987 has been marked as a duplicate of this bug. ***
*** Bug 259919 has been marked as a duplicate of this bug. ***
*** Bug 207050 has been marked as a duplicate of this bug. ***
*** Bug 174867 has been marked as a duplicate of this bug. ***
*** Bug 265227 has been marked as a duplicate of this bug. ***
*** Bug 261205 has been marked as a duplicate of this bug. ***
Andreas, could you have a look at this? Your commit r1181024 (git:ae408262) in kdelibs/kio/kssl says it "made rule finding in KSSLD more robust" but I can't find the corresponding changes in kdelibs/kdecore/network/kssld.
Ok, it was committed separately git: 1195c502 svn:1181082. Could this have broken exception rules?
My experience matches one of the dupes: https://bugs.kde.org/show_bug.cgi?id=174867#c3 Although the cert is trusted, it is issued by an unknown CA. If I import the CA's root cert the problem goes away. It should be possible to force kssl to accept the server cert even if the CA is unknown.
*** Bug 266453 has been marked as a duplicate of this bug. ***
I tried to reproduce the bug but it all worked fine here. I tested POP3 connections on: 85.25.71.152 mail.kourentas.com When first checking mail, I got asked to accept the certificate (and then login failed since I don't actually have an account there). When checking mail again, I didn't get asked to accept the certificate again, even after restarting Akonadi and KDE. The certificates are stored in $KDEHOME/share/config/ksslcertificatemanager, btw.
Hi! 2011/2/25 Thomas McGuire <mcguire@kde.org>: > --- Comment #16 from Thomas McGuire <mcguire kde org> 2011-02-25 15:55:56 --- > I tried to reproduce the bug but it all worked fine here. > > I tested POP3 connections on: > 85.25.71.152 > mail.kourentas.com > > When first checking mail, I got asked to accept the certificate (and then login > failed since I don't actually have an account there). > When checking mail again, I didn't get asked to accept the certificate again, > even after restarting Akonadi and KDE. > > The certificates are stored in $KDEHOME/share/config/ksslcertificatemanager, > btw. I have removed my cert store, but the problem remains... You could try to connect to ugs.tarent.de. You don't have a valid username+pwd, but the certificate should be stored nevertheless, right?
I've checked my $KDEHOME/share/config/ksslcertificatemanager -- the certificate is there. But sometimes I'm prompted whether or not I want to accept it anyway (at irregular intervals, sometimes it's a matter of minutes, sometimes a matter of days). Chances are that reading the certificate from the file fails (or mismatches) under some yet to be determined circumstances.
(In reply to comment #16) > I tried to reproduce the bug but it all worked fine here. > > I tested POP3 connections on: > 85.25.71.152 > mail.kourentas.com > > When first checking mail, I got asked to accept the certificate (and then login > failed since I don't actually have an account there). > When checking mail again, I didn't get asked to accept the certificate again, > even after restarting Akonadi and KDE. > > The certificates are stored in $KDEHOME/share/config/ksslcertificatemanager, > btw. First of all, I would once again like to thank you for your concern. Following your suggestion, I found and opened the file (that belongs to the user account by which I am running kde, and not somebody else's, i.e. root): $KDEHOME/share/config/ksslcertificatemanager, where I have also found the entry concerning the certificate of: mail.kourentas.com, which is followed by the following characteristics: mail.kourentas.com=ExpireUTC 3009-02-09T16:37:47,HostNameMismatch,InvalidCertificateAuthority,UntrustedCertificate,CertificateSignatureFailed I am not aware whether any of the above cases raises the reported issue (which btw persists): I am constantly (_not_ sometimes, but on _every_ iteration of mail check, that is every single minute, since that's the interval I have set for the particular email account) asked to accept the problematic certificate (regardless of me directing the system to explicitly accept it by taking the entire/full responsibility of that very action/decision). Btw, I could even create a test email account on the above mentioned domain (mail.kourentas.com) for you to perform any tests? Would such an account prove to be of any use to you? I would once again like to thank you for your concern, Should you have any further queries, I am at your disposal, Best regards, Nassos
> You don't have a valid username+pwd, but the certificate should be stored > nevertheless, right? Yep, making a connection is enough to test this, no account on the server is needed.
One thing that might potentially help is to see the debug output of KDE. Start "kdebugdialog" and enable the debug area for "kssl". After restarting, debug output should be available in $HOME/.xsession-errors, although it seems kssl doesn't have that much useful debug output.
Same here. KDE 4.6.0 with kmail 1.13.6. I previously killed .kde4/share/config/kssl* without any help. I enabled any "ssl" and "mail" in kdebugdialog but my .xsession-errors remains empty. However I capture my output elsewehere and within I see: --- 8< snip --- plasma-desktop(8711)/plasma Battery::dataUpdated: Remaining msecs on battery: 0 plasma-desktop(8711)/plasma Battery::dataUpdated: Remaining msecs on battery: 0 kontact(8993)/kio (Slave) KIO::Slave::createSlave: createSlave "imap" for KUrl("imap://D03%5CMaurhartO@localhost:4143") kontact(8993)/kio (KIOConnection) KIO::ConnectionServer::listenForRemote: Listening on "local:/tmp/ksocket-dyle/kontacteX8993.slave-socket" klauncher(8669)/kio (KLauncher) KLauncher::requestSlave: KLauncher: launching new slave "kio_imap4" with protocol= "imap" args= ("imap", "local:/tmp/ksocket-dyle/klauncherhX8669.slave-socket", "local:/tmp/ksocket-dyle/kontacteX8993.slave-socket") klauncher(8669)/kio (KLauncher) KLauncher::processRequestReturn: "kio_imap4" (pid 9084) up and running. kontact(8993)/kio (Scheduler) KIO::SchedulerPrivate::getConnectedSlave: KUrl("imap://D03%5CMaurhartO@localhost:4143") KIO::Slave(0x1e06af0) unnamed app(9084)/kio_imap kdemain: IMAP4::kdemain kio_imap4(9084)/kio_imap IMAP4Protocol::dispatch: IMAP4::dispatch - command= 85 kio_imap4(9084)/kio_imap IMAP4Protocol::dispatch: IMAP4::dispatch - command= 48 kio_imap4(9084)/kio_imap IMAP4Protocol::dispatch: IMAP4::dispatch - command= 49 kio_imap4(9084)/kio_imap IMAP4Protocol::makeLogin: IMAP4::makeLogin - checking login kio_imap4(9084)/kio_imap IMAP4Protocol::makeLogin: IMAP4::makeLogin - alreadyConnected false kio_imap4(9084)/kio (TCPSlaveBase) KIO::TCPSlaveBase::disconnectFromHost: kio_imap4(9084)/kio_imap IMAP4Protocol::makeLogin: myAuth: "NTLM" kio_imap4(9084)/kio_imap imapParser::parseLoop: imapParser::parseLoop - unhandledResponse: "* OK The Microsoft Exchange IMAP4 service is ready. " kio_imap4(9084)/kio_imap IMAP4Protocol::makeLogin: IMAP4: setHost: capability kio_imap4(9084)/kio_imap IMAP4Protocol::makeLogin: ' "imap4" ' kio_imap4(9084)/kio_imap IMAP4Protocol::makeLogin: ' "imap4rev1" ' kio_imap4(9084)/kio_imap IMAP4Protocol::makeLogin: ' "auth=ntlm" ' kio_imap4(9084)/kio_imap IMAP4Protocol::makeLogin: ' "auth=gssapi" ' kio_imap4(9084)/kio_imap IMAP4Protocol::makeLogin: ' "auth=plain" ' kio_imap4(9084)/kio_imap IMAP4Protocol::makeLogin: ' "starttls" ' kio_imap4(9084)/kio_imap IMAP4Protocol::makeLogin: ' "idle" ' kio_imap4(9084)/kio_imap IMAP4Protocol::makeLogin: ' "namespace" ' kio_imap4(9084)/kio_imap IMAP4Protocol::makeLogin: ' "literal+" ' kio_imap4(9084)/kssl KTcpSocket::showSslErrors: "The host name did not match any of the valid hosts for this certificate" kio_imap4(9084)/kssl KTcpSocket::showSslErrors: "The issuer certificate of a locally looked up certificate could not be found" kio_imap4(9084)/kssl KTcpSocket::showSslErrors: "The root CA certificate is not trusted for this purpose" kio_imap4(9084)/kssl KIO::TCPSlaveBase::startTLSInternal: Cipher info - advertised SSL protocol version 8 negotiated SSL protocol version 8 authenticationMethod: "RSA" encryptionMethod: "AES" keyExchangeMethod: "RSA" name: "AES128-SHA" supportedBits: 128 usedBits: 128 kio_imap4(9084)/kio (kioslave) KIO::SlaveBase::messageBox: messageBox 4 "The server failed the authenticity check (localhost). The certificate does not apply to the given host The certificate authority's certificate is invalid The root certificate authority's certificate is not trusted for this purpose" - "Server Authentication" "&Details" "Co&ntinue" kontact(8993)/kio (KIOJob) KIO::SlaveInterface::dispatch: needs a msg box kontact(8993)/kio (KIOJob) KIO::SlaveInterface::messageBox: messageBox 4 "The server failed the authenticity check (localhost). The certificate does not apply to the given host The certificate authority's certificate is invalid The root certificate authority's certificate is not trusted for this purpose" - "Server Authentication" "" kwin(8694) KWin::Client::readUserTimeMapTimestamp: User timestamp, ASN: 3638608 kwin(8694) KWin::Client::readUserTimeMapTimestamp: User timestamp, final: 'ID: 79754414 ;WMCLASS: "kontact" : "kontact" ;Caption: "Server Authentication â Kontact" ' : 3638608 kwin(8694) KWin::Workspace::updateClientArea: screens: 1 desktops: 4 kwin(8694) KWin::Workspace::updateClientArea: Done. kwin(8694) KWin::Workspace::createTile: Now tiling "Server Authentication â Kontact" kwin(8694) KWin::Workspace::updateClientArea: screens: 1 desktops: 4 kwin(8694) KWin::Workspace::updateClientArea: Done. kontact(8993)/kio (KIOJob) KIO::SlaveInterface::messageBox: KIO::Slave(0x1e06af0) SlaveInterface result= 4 kio_imap4(9084)/kio (kioslave) KIO::SlaveBase::messageBox: got messagebox answer 4 kio_imap4(9084)/kio (kioslave) KIO::SlaveBase::messageBox: messageBox 2 "Would you like to accept this certificate forever without being prompted?" - "Server Authentication" "&Forever" "&Current Session only" kontact(8993)/kio (KIOJob) KIO::SlaveInterface::dispatch: needs a msg box kontact(8993)/kio (KIOJob) KIO::SlaveInterface::messageBox: messageBox 2 "Would you like to accept this certificate forever without being prompted?" - "Server Authentication" "" kwin(8694) KWin::Client::readUserTimeMapTimestamp: User timestamp, ASN: 3640081 kwin(8694) KWin::Client::readUserTimeMapTimestamp: User timestamp, final: 'ID: 79755759 ;WMCLASS: "kontact" : "kontact" ;Caption: "Server Authentication â Kontact" ' : 3640081 kwin(8694) KWin::Workspace::updateClientArea: screens: 1 desktops: 4 kwin(8694) KWin::Workspace::updateClientArea: Done. kwin(8694) KWin::Workspace::createTile: Now tiling "Server Authentication â Kontact" kwin(8694) KWin::Workspace::updateClientArea: screens: 1 desktops: 4 kwin(8694) KWin::Workspace::updateClientArea: Done. kontact(8993)/kio (KIOJob) KIO::SlaveInterface::messageBox: KIO::Slave(0x1e06af0) SlaveInterface result= 3 kio_imap4(9084)/kio (kioslave) KIO::SlaveBase::messageBox: got messagebox answer 3 kio_imap4(9084)/kssl KIO::TCPSlaveBase::startTLSInternal: server certificate verification failed but continuing at user's request. kio_imap4(9084)/kio_imap IMAP4Protocol::makeLogin: TLS mode has been enabled. kio_imap4(9084)/kio_imap IMAP4Protocol::makeLogin: ' "imap4" ' kio_imap4(9084)/kio_imap IMAP4Protocol::makeLogin: ' "imap4rev1" ' kio_imap4(9084)/kio_imap IMAP4Protocol::makeLogin: ' "auth=ntlm" ' kio_imap4(9084)/kio_imap IMAP4Protocol::makeLogin: ' "auth=gssapi" ' kio_imap4(9084)/kio_imap IMAP4Protocol::makeLogin: ' "auth=plain" ' kio_imap4(9084)/kio_imap IMAP4Protocol::makeLogin: ' "idle" ' kio_imap4(9084)/kio_imap IMAP4Protocol::makeLogin: ' "namespace" ' kio_imap4(9084)/kio_imap IMAP4Protocol::makeLogin: ' "literal+" ' kio_imap4(9084)/kio_imap IMAP4Protocol::makeLogin: IMAP4::makeLogin - attempting login kio_imap4(9084)/kio_imap IMAP4Protocol::makeLogin: IMAP4::makeLogin - open_PassDlg said user= "D03\MaurhartO" pass=xx kio_imap4(9084)/kio_imap imapParser::clientAuthenticate: aAuth: "NTLM" FQDN: "localhost" isSSL: false kio_imap4(9084)/kio_imap sasl_interact: sasl_interact kio_imap4(9084)/kio_imap sasl_interact: SASL_INTERACT id: 16386 kio_imap4(9084)/kio_imap sasl_interact: SASL_CB_[USER|AUTHNAME]: ' "D03\MaurhartO" ' kio_imap4(9084)/kio_imap sasl_interact: SASL_INTERACT id: 16388 kio_imap4(9084)/kio_imap sasl_interact: SASL_CB_PASS: [hidden] kontact(8993)/kio (KIOJob) KIO::SlaveInterface::dispatch: error 163 "Unable to authenticate via NTLM. The server localhost replied: AUTHENTICATE failed." kontact(8993)/kio (Scheduler) KIO::SchedulerPrivate::slotSlaveError: KIO::Slave(0x1e06af0) 163 "Unable to authenticate via NTLM. The server localhost replied: AUTHENTICATE failed." plasma-desktop(8711)/plasma SwitchDesktop::wheelEvent: 2 -120 --- snap >8 --- Which finally pointed me to my (other) login problem with the MS Exchange server ... I used NTLM login instead of Clear Text. KMail didn't tell me what the server wants. After choosing the right login method, no certificate question arises any longer until I log out. The next log in I am asked again.
(In reply to comment #21) > One thing that might potentially help is to see the debug output of KDE. > Start "kdebugdialog" and enable the debug area for "kssl". After restarting, > debug output should be available in $HOME/.xsession-errors, although it seems > kssl doesn't have that much useful debug output. After performing the above steps (including restarting the entire KDE) I get the following whenever the system attempts to check for new emails (that is every single minute) in the .xsession-errors file: <begin> ... kio_pop3(10429)/kssl: "The host name did not match any of the valid hosts for this certificate" kio_pop3(10429)/kssl: "The issuer certificate of a locally looked up certificate could not be found" kio_pop3(10429)/kssl: "The root CA certificate is not trusted for this purpose" kio_pop3(10429)/kssl: "No certificates could be verified" kio_pop3(10429)/kssl KIO::TCPSlaveBase::startTLSInternal: Cipher info - advertised SSL protocol version 8 negotiat ed SSL protocol version 8 authenticationMethod: "RSA" encryptionMethod: "AES" keyExchangeMethod: "DH" name: "DHE- RSA-AES256-SHA" supportedBits: 256 usedBits: 256 kio_pop3(10429)/kssl KIO::TCPSlaveBase::startTLSInternal: server certificate verification failed but continuing at us er's request. akonadi_pop3_resource_2(5770)/kio (KIOJob) KIO::TransferJob::slotData: mimeType() not emitted when sending first data !; job URL = KUrl("pop3://nassos%40kourentas.com@mail.kourentas.com:110/index") data size = 0 akonadi_pop3_resource_2(5770)/kio (KIOJob) KIO::TransferJob::slotData: mimeType() not emitted when sending first data !; job URL = KUrl("pop3://nassos%40kourentas.com@mail.kourentas.com:110/uidl") data size = 0 akonadi_pop3_resource_2(5770)/kio (KIOJob) KIO::TransferJob::slotData: mimeType() not emitted when sending first data !; job URL = KUrl("pop3://nassos%40kourentas.com@mail.kourentas.com:110/download/") data size = 0 ... <end> I would once again like to underline the fact that the above output is repeated _every_ time kontact (kmail) is attempting to check for new emails at the server whose certificate cannot be determined whether it's valid or not (and I explicitly request the forever acceptance of it).
*** Bug 267698 has been marked as a duplicate of this bug. ***
To the best of my knowledge, since upgrading to KDE 4.6.1 (from the openSuSE repositories) the bug has been resolved. I would like to thank everyone involved in the entire process! Nassos
Nope. I'm using KDE SC 4.6.1 and it's still here.
(In reply to comment #26) > Nope. I'm using KDE SC 4.6.1 and it's still here. Same here. Using KDE 4.6.1 and KMail still don't want to remember self-signed certificates.
I solved this problem for me creating my own CA which I added to Kleopatra. I then used that CA for signing my personal Dovecot's server certificate. No more popups.
Same here: Kmail 1.13.6, KDE 4.6.1 Interessting: today I made an yum -y update (since 31.3.2011), before this update all was fine...
We experience the same problem here with Kontact (downloading address book from eGroupWare on server with self-signed certificate) and Konqueror (accessing the same server via https). The problem occurred with KDE 4.6.1 and persists after an upgrade to KDE 4.6.2. A KDE 4.4.5 installation was not affected. Removing the user-specific KDE settings in the user's home folder did not help.
Kmail prompts every time Email is sent/received whether to accept the certificate. Selecting 'forever' seems to have no effect. Two pop-ups are presented by Kmail: 1) "The server failed the authenticity check (localhost). The certificate does not apply to the given host" 2) "Would you like to accept this certificate forever without being prompted?" >> Selecting Forever makes no difference. System info: OpenSuse 11.4 KDE 4.6.0 Kontact 4.4.10 Kmail 1.13.6
(In reply to comment #31) > Kmail prompts every time Email is sent/received whether to accept the > certificate. Selecting 'forever' seems to have no effect. > > Two pop-ups are presented by Kmail: > 1) "The server failed the authenticity check (localhost). > The certificate does not apply to the given host" > > 2) "Would you like to accept this certificate forever without being prompted?" > >> Selecting Forever makes no difference. > > System info: > OpenSuse 11.4 > KDE 4.6.0 > Kontact 4.4.10 > Kmail 1.13.6 Now running KDE 4.6.2; however, the problem persists.
*** Bug 272701 has been marked as a duplicate of this bug. ***
(In reply to comment #32) > (In reply to comment #31) > > Kmail prompts every time Email is sent/received whether to accept the > > certificate. Selecting 'forever' seems to have no effect. > > > > Two pop-ups are presented by Kmail: > > 1) "The server failed the authenticity check (localhost). > > The certificate does not apply to the given host" > > > > 2) "Would you like to accept this certificate forever without being prompted?" > > >> Selecting Forever makes no difference. > > > > System info: > > OpenSuse 11.4 > > KDE 4.6.0 > > Kontact 4.4.10 > > Kmail 1.13.6 > > > Now running KDE 4.6.2; however, the problem persists. Issue still exists in KDE 4.6.3/Kontact 4.4.11/Kmail 1.13.7
Hi, it is still the same with kde 4.6.80 ! By the way, it is not only self-signed certificates but also the ones not matching the host. For example here I have to use a ssh tunnel to connect my imap server, so my server host is localhost!
I am experiencing this problem too when trying to download email in KMail. I am moving away from ThunderBird and did not get this error. I tried Evolution yesterday and did not get this error. Now I am trying out KMail and I am consistently getting this error on three domains. Server Authentication - KMail The server failed the authenticity check (mail.<each domain name). The certificate does not apply to the given host. I have tried changing encryption from TLS to SSL, changing the certificate chain, selecting "accept certificate forever". This is KMail version 1.13.5, kde 4.4.5, Ubuntu 10.04, kernel Linux 2.6.32-32-generic, GNOME 2.30.2
For all those that are having this problem. Please check your ksslcertificatemanager file and see what expiration date, if any is included with the certificate stored for that particular site. The site and expiration date information are located after the "\n-----END CERTIFICATE-----\n" entry. The same issue was reported against konqueror, see bug#132761, but I am unable to duplicate the problem. I never get prompted once I chose for it to be saved forever.
There is a date. It's of this Tuesday, which is not when the certificate expires.
(In reply to comment #37) > For all those that are having this problem. Please check your > ksslcertificatemanager file and see what expiration date, if any is included > with the certificate stored for that particular site. The site and expiration > date information are located after the "\n-----END CERTIFICATE-----\n" entry. Here it is: atom=ExpireUTC 3011-05-08T19:16:44,SelfSignedCertificate The actual expiration date of this certificate is 2012-04-01 17:30:10.
(In reply to comment #39) > (In reply to comment #37) > > For all those that are having this problem. Please check your > > ksslcertificatemanager file and see what expiration date, if any is included > > with the certificate stored for that particular site. The site and expiration > > date information are located after the "\n-----END CERTIFICATE-----\n" entry. > > Here it is: > > atom=ExpireUTC 3011-05-08T19:16:44,SelfSignedCertificate > > The actual expiration date of this certificate is 2012-04-01 17:30:10. And you still get prompted again ? Is this from kmail ?
(In reply to comment #38) > There is a date. It's of this Tuesday, which is not when the certificate > expires. (In reply to comment #38) > There is a date. It's of this Tuesday, which is not when the certificate > expires. Let me see if I get what you are saying. The expiration date saved in $KDEHOME/share/config/ksslcertificatemanagerrc when you elected to accept the "invalid" certificate forever is next Tuesday ? For what it is worth I get the following using current git master: <server-address>=ExpireUTC 3011-06-11T16:22:45,SelfSignedCertificate
(In reply to comment #40) > [snip] > > And you still get prompted again ? Is this from kmail ? Yes, kmail will prompt me for each of the 10 email accounts that use this certificate when I start it. Then, kmail happily checks the server each 5 minutes for new emails without prompting me until I stop it.
(In reply to comment #42) > (In reply to comment #40) > > [snip] > > > > And you still get prompted again ? Is this from kmail ? > > Yes, kmail will prompt me for each of the 10 email accounts that use this > certificate when I start it. > > Then, kmail happily checks the server each 5 minutes for new emails without > prompting me until I stop it. What kind of email accounts do you have ? pop3, ldap ? This seems to be a protocol specific issue. That is, whatever kioslave is used to retrieve your emails seems not to use TCPSlaveBase. I most definitely cannot duplicate it using the http ioslave and a self-signed SSL certificate.
Looks like, at least in my case, there may have been a problem with the local certificate in dovecot causing the issue here with kmail. I regenerated the ssl certificate with the mkcert.sh script from dovecot, then setup the owners and perms correctly for /etc/ssl/private/dovecot.pem. The problem has now disappeared. There is a excellent write up on this procedure at http://wiki1.dovecot.org/SSL/CertificateCreation for those in need of the procedure.
The problem (for me at least) is not to do with the certificate, I know its an untrusted certificate, but after I have told kmail to use it nevertheless "forever" , the next time kmail is started it asks me again whether to accept it, i.e. it has "forgotten” my instruction to accept it forever. Kmail is using IMAP to connect to a dovecot server which comes with a pre-generated key which kmail quite rightly detects as untrusted , so the problem is not in KDE's handling of the certificate (its quite rightly complaining about the certificate) the problem is that you can no longer tell kmail that you do in fact trust this certificate so that it remembers it the next time it is started.
(In reply to comment #43) > (In reply to comment #42) > > (In reply to comment #40) > > > [snip] > > > > > > And you still get prompted again ? Is this from kmail ? > > > > Yes, kmail will prompt me for each of the 10 email accounts that use this > > certificate when I start it. > > > > Then, kmail happily checks the server each 5 minutes for new emails without > > prompting me until I stop it. > > What kind of email accounts do you have ? pop3, ldap ? This seems to be a > protocol specific issue. That is, whatever kioslave is used to retrieve your > emails seems not to use TCPSlaveBase. > > I most definitely cannot duplicate it using the http ioslave and a self-signed > SSL certificate. All of these 10 accounts use the imap protocol, and kio_imap4 is used by kmail as shown by "ps x": 2455 ? Sl 0:14 /usr/bin/kmail -caption KMail 2464 ? S 0:00 kdeinit4: kio_imap4 [kdeinit] imap local:/tmp/ksocket-alain/klauncherMT1683.slave-socket local:/tmp/ksocket-alain/kmailBz2455.slave-socket 2465 ? S 0:00 kdeinit4: kio_imap4 [kdeinit] imap local:/tmp/ksocket-alain/klauncherMT1683.slave-socket local:/tmp/ksocket-alain/kmailWr2455.slave-socket 2466 ? S 0:00 kdeinit4: kio_imap4 [kdeinit] imap local:/tmp/ksocket-alain/klauncherMT1683.slave-socket local:/tmp/ksocket-alain/kmailHZ2455.slave-socket 2467 ? S 0:00 kdeinit4: kio_imap4 [kdeinit] imap local:/tmp/ksocket-alain/klauncherMT1683.slave-socket local:/tmp/ksocket-alain/kmailll2455.slave-socket 2468 ? S 0:00 kdeinit4: kio_imap4 [kdeinit] imap local:/tmp/ksocket-alain/klauncherMT1683.slave-socket local:/tmp/ksocket-alain/kmailrc2455.slave-socket 2469 ? S 0:00 kdeinit4: kio_imap4 [kdeinit] imap local:/tmp/ksocket-alain/klauncherMT1683.slave-socket local:/tmp/ksocket-alain/kmailYM2455.slave-socket 2470 ? S 0:00 kdeinit4: kio_imap4 [kdeinit] imap local:/tmp/ksocket-alain/klauncherMT1683.slave-socket local:/tmp/ksocket-alain/kmailEV2455.slave-socket 2471 ? S 0:00 kdeinit4: kio_imap4 [kdeinit] imap local:/tmp/ksocket-alain/klauncherMT1683.slave-socket local:/tmp/ksocket-alain/kmailkR2455.slave-socket 2472 ? S 0:00 kdeinit4: kio_imap4 [kdeinit] imap local:/tmp/ksocket-alain/klauncherMT1683.slave-socket local:/tmp/ksocket-alain/kmailtj2455.slave-socket 2475 ? S 0:00 kdeinit4: kio_imap4 [kdeinit] imap local:/tmp/ksocket-alain/klauncherMT1683.slave-socket local:/tmp/ksocket-alain/kmailqH2455.slave-socket
Well... I hate to report I was mistaken in that I though the new cert solved it here.. but it didn't. It's still acting like Deri described it above and not remembering the local exception.
My Case: The Expiration date in ksslcertificatemanager is always the date, when I first connected to the email-server plus 1000 Years: localhost=ExpireUTC 3011-06-14T09:43:05,HostNameMismatch (Still asking me if I want to accept the invalid certificate once a minute...)
I "solved" the problem by removing $KDEHOME/share/config/ksslcertificatemanager and then rebooting. And now it seems ok. And before that, I had the problem with every protocol possible, smtp, pop, imap and https.
Unfortunately, removing "$KDEHOME/share/config/ksslcertificatemanager" and rebooting did not help here. I still get asked whether I want to store the certificate even if I had chosen to remember it forever before. Similar to what others have already described, the certificate is stored in the ksslcertificatemanager with an expiration date in 1000 years. But the question whether to remember it keeps coming up.
I think there are in fact two separate problems described in this thread. The original bug report deals with the failure of kde to honour a request to trust "forever", so on each kmail startup you have to accept the certificate again. Other reports indicate repetitive asking to trust a certificate during the same session, and this problem may be cured by removal of the ksslcertificatemanager file, but the original bug where it does not mark the certificate as permanent still remains.
I suggest to read comment #3, from Patrick Cornelissen (the original reporter), he did mention the need for repetitive asking to trust a certificate. I am not saying that it is not two different bugs, but this bug appears to be about repetitive asking.
Correct, Kontact asks each time.
I had this too and after looking at the code some my issue was fixed by making sure that the cert is for the same hostname as I used to connect to (i.e. foo.bar.org and not just foo since it was a local server).
We do not experience the problem anymore under KDE 4.6.5. It seems to have been solved.
Hi, I'm still seeing this issue with a self signed certificate used for a local dovecot server (KDE and kdepim 4.7.1). Akonadi always asks to trust the certificate at start-up. The certificate is correctly stored in $KDEHOME/share/config/ksslcertificatemanager with the following characteristics: localhost=ExpireUTC 3011-09-29T21:50:37,InvalidCertificateAuthority,UntrustedCertificate,CertificateSignatureFailed My issue may be in the KSSLD::rule method in kdecore/network/kssld/kssld.cpp As I understand it, hostnames without at least 2 parts are ignored when reading the config file. So my 'localhost' exception is ignored. I don't know if there is a reason for this. I'm attaching a straightforward patch tested on my gentoo linux box to allow hostnames without dot.
Created attachment 64080 [details] accept hostnames in one part
Tested on my network. Simple hostname « mailsrv » leads to the remember bug (for SMTP only, IMAP seems remembered correctly). FQDN « mailsrv.foo.bar » fix the problem. So, seems the patch on #57 comment may fix this bug.
FWIW, my self-signed certificate was also made for a single part hostname ("atom", which was defined in the /etc/hosts file of the client computer). So Florent Bondoux's patch may solve the issue. I didn't test it since I am now using a free CA-signed certificate with a fully qualified hostname.
Git commit aea796939841c1d024cebec3b9ef578fc947a14a by Dawit Alemayehu. Committed on 08/10/2011 at 16:41. Pushed by adawit into branch 'KDE/4.7'. Correctly apply the policy for self signed certificates with unqualified hostnames, e.g. localhost. Credit for this patch goes to Florent Bondoux. BUG: 233628 FIXED-IN: 4.7.3 M +7 -6 kdecore/network/kssld/kssld.cpp http://commits.kde.org/kdelibs/aea796939841c1d024cebec3b9ef578fc947a14a
*** Bug 275021 has been marked as a duplicate of this bug. ***
*** Bug 132761 has been marked as a duplicate of this bug. ***
*** Bug 130207 has been marked as a duplicate of this bug. ***
*** Bug 261337 has been marked as a duplicate of this bug. ***
*** Bug 114797 has been marked as a duplicate of this bug. ***
I am hitting this with KDE 4.11.2 and Akonadi IMAP repeatedly asking even after selecting forever.
I'm having a similar issue in 4.8.4 (Debian) I found that I could fix it if the server's certificate also contains the certificate of the CA.
After an openssl update (openSUSE 13.1/x86_64), I found my desktop with hundreds of these dialogs opened (using two internal self signed imap servers here). I believe, that it was related to the update, but asking for the same server more than once, when the former dialog is shown already, is a bug.
Any Updates here, i was a few days absent and found nearly hundred of cert questions on my desktop. Its Im Using KMail 4.14
If still you have SSL dialog issues with in kmail, then please open a new bug report against kdepim/kmail. The last I remember kmail use kdepim which relies on its own method of storing certificates through kleopatra. IOW, if you cannot reproduce the problem with Konqueror or reKonq when vising secure sites that fail SSL certificate verification, then the issue is not a KIO issue.
I indeed cannot reproduce this problem with konquerer. However I still have the problem with kmail and found a similar report with product kmail2: bug 308968
I hate to reopen old bugs, but after a long time of silence, some changes during this year made it reappear. I still have/need access to an old imap server (from a liquidated company) in my local network (openSUSE 11.1, cyrus imap, self signed certificate). On my Tumbleweed desktop (20191210), I suffer from this issue since a few weeks with various degrees of severity, up to a complete *DOS* (kscreenlocker_greet shows a time in the past, almost always 04:4?, but no login) of my system (all KDE/KF5). Since I needed to reboot my system today morning again due to this very issue, I decided to track this down: killing the kscreenlocker* allowed me to take a look, and guess what: it shows "Server Authentication" warnings [SAW], up to the point of kwin crashing (no window handles, no screen switching, ...). Here are some interesting details: I've added the root and imap certificate in Kleopatra a while ago, where it is shown under Trusted certificates. (All screen texts are translated from german on the fly, bear with me). I can easily provoke the SAW once by restarting Kmail, but restarting akonadi will trigger the SAW once *every* *30* *seconds*. Looks, like something triggers an akonadi restart early in the morning, but that's not the point. Recreating .config/ksslcertificatemanager reveals another funny detail: the format changed over time, now it looks similar to: [95a0e3fca10d38c8420639952ad508c1] imap.local.domain=ExpireUTC 3019-12-12T13:33:39,SelfSignedCertificateInChain and every time, I confirm to persist the certificate, the ExpireUTC value changes. So here's a summary: * kwin should never crash if too many dialogs are shown * the SAW should never shown more than once * kio doesn't associate accepted certificates correctly
So here's a summary (corrected): * kwin should never crash, even if too many dialogs are attempted to be shown * the SAW should *never* be shown more than once for a single host * kio saves the persisted certificates correctly, but fails to associate them when loading/checking again .config/ksslcertificatemanager: In former times, an entry used to contain a CertificatePEM= field, that vanished now. I tried to make some sense from ksslcertificatemanager.{h,cpp} and git log, but the transitioning to kssld and QSslError makes it hard to spot the spot, where this issue was {re}introduced. I suspect a relation to the newly invented filtering...
Which versions of KIO and KIMAP do you have?
Tumbleweed tends to be pretty current: kio: 5.64.0 kimap: 19.08.3 These are the related projects: https://build.opensuse.org/package/show/openSUSE:Factory/kio https://build.opensuse.org/package/show/openSUSE:Factory/kimap The build logs are available in the <Build Results> block.
Created attachment 124452 [details] 6 minutes after akonadi start without confirming these requests Needless to say, that these requests must *all* be answered for the same host. That issue exists since the beginning of time (I remember confirming piles of such dialogs in the past (in KDE4 times..). If you need more details or want me to do some tests, let me know. I'm ready and prepared to apply patches, if you can point me to some commits or diffs.
With KIO 5.64/5.65 and a stand-alone test case (https://invent.kde.org/vkrause/http-demo) I can reproduce this against https://untrusted-root.badssl.com/ (and only that, https://self-signed.badssl.com/ works for example). With master it works, which would suggest https://phabricator.kde.org/D25371 is what fixes it on top of 5.65 (if that's all that's needed on top of 5.64 seems questionable though).
Dear Volker, thank you very much. I hereby confirm, that D25371 on top of kio 5.64 fixes the most apparent impact of this issue after regenerating .config/ksslcertificatemanager (that was: repeatedly displaying the SAW for already confirmed hosts). While you improved the interoperability with *some* self signed certificates for about 100%, a few notes are due, though. My newly generated .config/ksslcertificatemanager contains in total 3 digests with 4 hosts (one exists with both name and ip address). I would expect that code to ask exactly 4 times (once for each host), but it asked for every *account* once, and since I didn't confirm all the SAWs in the first 30 seconds (I was delayed for about 2 minutes), I had to confirm about 30 requests for my 8 accounts(!). The certificate manager might need to flag certificates with pending requests and, hmm, block subsequent requests?!? The need for regenerating .config/ksslcertificatemanager implies some issues with upgrading from old errors to new ones: Here's the diff of them: -192.168.2.4=ExpireUTC 3019-03-21T20:24:03,HostNameMismatch,InvalidCertificateAuthority,CertificateSignatureFailed +192.168.2.4=ExpireUTC 3019-12-13T11:29:11,HostNameMismatch,UnableToGetLocalIssuerCertificate,UnableToVerifyFirstCertificate -somewhere.org=ExpireUTC 3019-06-13T18:22:39,InvalidCertificateAuthority,CertificateSignatureFailed +somewhere.org=ExpireUTC 3019-12-13T11:28:34,UnableToGetLocalIssuerCertificate,UnableToVerifyFirstCertificate -local.host=ExpireUTC 3019-11-15T10:17:40,SelfSignedCertificate +local.host=ExpireUTC 3019-12-13T11:29:24,SelfSignedCertificateInChain It might be better to just silently remove the old (unknown) ones. During the experiments yesterday, it managed to create one entry, that was missing a CertificatePEM= field. Most probably by removing .config/ksslcertificatemanager, while akonadi was still running. That entry didn't gained that field again during the reboots today, but only after manually removing the key, and let kio regenerating the full key on reboot. One thing, that nags me from this experience is the DOS behaviour. Any idea, how to precede with this one? And another: since GB is definitely leaving the EU now, their significance will cease. Should we (try to) stick with British English, or fully turn to the chewing gum version of it in global communications?
Thanks for the feedback. I'll see if we can still get that patch into the 5.65 release due tomorrow. The repeated display of this dialog is of course not addressed by this patch, that's an issue in the code using this (ie. Akonadi/KIMAP), and this needs to be addressed there. The changes in how the SSL error exceptions are stored are a side-effect of the migration to QSslError (that's the changes in KIO triggering all this). This gives us a much more fine-grained error reporting compared to the old KSslError, which makes it not always possible to properly map this to the old values though. That's the case you hit, and all that should be needed in this case is a single confirmation of the exception again. In combination with KIMAP looping on this, this however entirely blew up for you (I guess the same would happen with a new account, so this needs to be addressed either way).
It would be just great to get it into 5.65. You can add my tested-by tag, if that helps. Let's keep this issue open, until the major issues, that concerns kio, are finally addressed. Thanks again, please leave a note about the acceptance. If you cannot get that into the next release, I will submit this patch for openSUSE as a temporary measure..
The change has been added to the 5.65.0 KIO release tarball.