| Summary: | bad error message when S/MIME crl's are not reachable | ||
|---|---|---|---|
| Product: | [Applications] kmail2 | Reporter: | kolAflash <kolAflash> |
| Component: | crypto | Assignee: | kdepim bugs <kdepim-bugs> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | ao, jansen |
| Priority: | NOR | ||
| Version: | 4.14.7 | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
kolAflash
2015-08-27 14:57:38 UTC
I also have a problem with this in Plasma 5 (Frameworks 5.19.0, Plasma 5.5.5, Apps 15.12.1) until I uncheck the checkbox you mentioned ("Never consult a CRL").
In one distrubution (Gentoo), at some times I couldn't re-select my certificate in KMail's Identity Settings and in email list it will show that it couldn't check signature (even though Kleopatra shows this cert as valid if I click on its fingerprint in KMail).
In Arch I can't even select the certificate in Identity settings — a popup window is shown which is on display forever, until I click Cancel.
I agree CRL handling must be done better.
I have to add that even though CRL URL is reachable in terms of network connection (I can download it with wget), there are still problems with using S/MIME in KMail when "Never consult a CRL" is unchecked. I also mistyped in my previous comment: "uncheck" -> "check". I seem to have the same problem on current tumbleweed distro. Things worked fine, however, untill about 2 weeks ago when suddenly KMail started refusing my s/mime certificate for my mail identity. Kleopatra at the same time still showed the the certificate as privat/secret, valid and trusted. On the other hand, "gpgsm --sign somefile.txt" no longer worked: ~> LC_ALL=C gpgsm --sign somefile.txt gpgsm: certificate is not usable for signing gpgsm: certificate is not usable for signing gpgsm: certificate is not usable for signing gpgsm: certificate is not usable for signing gpgsm: certificate not found: Ambiguous name gpgsm: certificate #1A1A2E4...,CN=h...,OU=R...,O=...,C=DE gpgsm: checking the CRL failed: Not found gpgsm: error creating signature: Not found <GpgSM> Using "gpgsm --disable-crl-check --sign somefile.txt" worked. Perhaps related: ~> LC_ALL=C dirmngr --fetch-crl 'http://pki.telesec.de/cgi-bin/service/af_DownloadARL.crl?-crl_format=X_509&-issuer=DT_ROOT_CA_2' dirmngr[5983.0]: permanently loaded certificates: 0 dirmngr[5983.0]: runtime cached certificates: 0 dirmngr[5983.0]: error fetching certificate by S/N: Configuration error dirmngr[5983.0]: CRL issuer certificate (#26/CN=Deutsche Telekom Root CA 2,OU=T-TeleSec Trust Center,O=Deutsche Telekom AG,C=DE) not found dirmngr[5983.0]: crl_parse_insert failed: Missing certificate dirmngr[5983.0]: processing CRL from 'http://pki.telesec.de/cgi-bin/service/af_DownloadARL.crl?-crl_format=X_509&-issuer=DT_ROOT_CA_2' failed: Missing certificate while "gpgsm -k" lists this cert: ID: 0x8CDE37BF S/N: 26 Issuer: /CN=Deutsche Telekom Root CA 2/OU=T-TeleSec Trust Center/O=Deutsche Telekom AG/C=DE Subject: /CN=Deutsche Telekom Root CA 2/OU=T-TeleSec Trust Center/O=Deutsche Telekom AG/C=DE validity: 1999-07-09 12:11:00 through 2019-07-09 23:59:00 key type: 2048 bit RSA key usage: certSign crlSign chain length: 5 fingerprint: 85:A4:08:C0:9C:19:3E:5D:51:58:7D:CD:D6:13:30:FD:8C:DE:37:BF Disabling the usage of CRLs in KMail and Kleopatra settings "fixed" the problems (except for the dirmngr command shown above). After reading through the comments again I come to think that - if all reports here are really about the same underlying problem - this is probably the wrong place for reporting the problem. Given my own observations that the command line applications are also affected, this shouldn´t be related to KDE (unless some KDE app somehow breaks the crypto configuration of the whole system). Thank you for reporting this bug in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "CONFIRMED" when replying. Thank you! 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 mark the bug 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! This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now 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 Thank you for helping us make KDE software even better for everyone! Can't actually reproduce this now (but also did not try very hard) - but in hindsight the original problem might have been using plain "http" URLs for accessing the CRL instead of "https"? |