Bug 351861 - bad error message when S/MIME crl's are not reachable
Summary: bad error message when S/MIME crl's are not reachable
Alias: None
Product: kmail2
Classification: Applications
Component: crypto (show other bugs)
Version: 4.14.7
Platform: OpenSUSE Linux
: NOR normal with 25 votes (vote)
Target Milestone: ---
Assignee: kdepim bugs
Depends on:
Reported: 2015-08-27 14:57 UTC by kolAflash
Modified: 2016-06-08 15:08 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Note You need to log in before you can comment on or make changes to this bug.
Description kolAflash 2015-08-27 14:57:38 UTC
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.

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.
Comment 1 Pavel 2016-03-07 08:38:03 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.
Comment 2 Pavel 2016-03-07 08:49:12 UTC
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".
Comment 3 jansen 2016-06-07 14:37:10 UTC
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).
Comment 4 jansen 2016-06-08 15:08:34 UTC
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).