If a message could not be encrypted and send, because the receivers S/MIME certificate crls (certificate revocation lists) are not reachable, the only error message is: "Could not compose message: Not found". That's as unhelpful as possible! Only way to workaround: Kleopatra => Settings => Configure Kleopatra => S/MIME => check "Never consult a CRL" Two possible solutions: 1. Replace error message with something more precise for this situation. E.g. "Couldn't verify receivers S/MIME certificate, because it's revocation urls are not reachable." 2. Additionally give the user the possibility, to ignore that the crls could not be reached. Those are the actual revocation urls used in the receivers S/MIME certificate. If the original, full S/MIME certificate is helpful for you, tell me and I'll ask the owner if I can publish it here. http://cdp1.pca.dfn.de/haw-hamburg-ca/pub/crl/g_cacrl.crl http://cdp2.pca.dfn.de/haw-hamburg-ca/pub/crl/g_cacrl.crl http://cdp1.pca.dfn.de/haw-hamburg-ca/pub/cacert/g_cacert.crt http://cdp2.pca.dfn.de/haw-hamburg-ca/pub/cacert/g_cacert.crt Reproducible: Always Steps to Reproduce: 1. Write an S/MIME encrypted+signed email to a receiver you have a S/MIME certificate for, which crls are not reachable. 2. Click "Send". 3. KMail may tell you: "One or more of the OpenPGP encryption keys or S/MIME certificates for recipient "..." is not fully trusted for encryption. The following keys or certificates have unknown trust level: ..." Click "Continue". 4. KMail will show you the "Encryption Key Approval" window. Click "OK". Actual Results: KMail will show you twice a message "Could not compose message: Not found". Expected Results: Send and encrypt message. Bug also appears in another place. 1. Send an S/MIME encrypted email to an receiver you don't have an S/MIME certificate for. 2. When sending, KMail will ask you: "There are conflicting encryption preferences for these recipients. Encrypt this message?" Click "Encrypt". 3. KMail will ask you for a certificate for the receiver. Now search for a certificate which is valid but has non working crls. 4. Before you click the line containing the certificate, at the left there will be an icon containing an question-mark. 5. Click at the certificate. The question-mark will change to a red X and you'll not be able to click "OK". Also in this case, there should be an explanation what's wrong about the certificate and maybe also an possibility to send+encrypt the email anyway with that key.
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"?