1944810 - Allow testing of a configured personal S/MIME certificate and seeing the reason when it's unusable

Status: RESOLVED FIXED

(MailNews Core :: Security: S/MIME, enhancement)

Description

[Kai Engert [:KaiE:]]

Implement the functionality explained in bug 1735832 comment 15.

Allow testing of a configured personal S/MIME certificate and seeing the reason when it's unusable.

Comment 1

[Kai Engert [:KaiE:]]

Attachment: Bug 1944810 - Allow testing of a configured personal S/MIME certificate and display the reason when it's unusable. r=mkmelin

Comment 2

[Kai Engert [:KaiE:]]

For example, this would help the user from bug 1939637, who reports that their certificates don't work in Thunderbird, and it would help me, because I could point the user to this test, and get the reason for failure easily.

Comment 3

[Kai Engert [:KaiE:]]

I've implemented the current patch on top of bug 1944707.

In theory, if we cannot move forward with 1944707, we could adjust the patch to work without.

Comment 4

[Kai Engert [:KaiE:]]

Attachment: existing UI

Comment 5

[Kai Engert [:KaiE:]]

Attachment: proposed UI

Comment 6

[Kai Engert [:KaiE:]]

Martin, what's your opinion on this UI change?

If you compare the two images, the difference is in the lower right area. Two buttons labeled "Test" are added.

The purpose is to test whether the selected certificate is actually usable.
A certificate that was configured (just now or in the past) might not be usable for a variety of reasons.

After clicking the button, the user would either get a success message, or a failure, with a detailed explanation why the certificate isn't considered valid.

I believe this functionality will allow users to self-diagnose. It will allow me to understand why things don't work for users. Something that is impossible to do remotely in many scenarios.

Comment 7

[Magnus Melin [:mkmelin]]

I guess we could also just do validation then loading the page, and have warning text beneath problematic certificates.

Comment 8

[Kai Engert [:KaiE:]]

(In reply to Magnus Melin [:mkmelin] from comment #7)

I guess we could also just do validation then loading the page, and have warning text beneath problematic certificates.

I'm afraid we cannot use that approach.

If a user has a smartcard, looking up and verifying the certificate can prompt the user to enter their smartcard pin.
I think that shouldn't happen when you simply open the prefs. It should only happen when the user attempts to use a certificate.

As a result, to avoid such prompts, when following your suggestion to automatically verify the selected cert whenever we open the prefs, we'd have to exclude such certificates (and I'm not even sure we could reliable distinguish and exclude them). Even if we excluded them, then user wouldn't get the status information, and would still require a way to manually verify the cert.

Furthermore, the verification of a certificate can take a couple of seconds (because of network OCSP checks).

For that reason, I think it's best to introduce a way to manually trigger a check of the configured cert.

Comment 9

[Kai Engert [:KaiE:]]

See bug 1481969 for many scenarios in which users tried to use a certificate, but it didn't work.
The feature here should help those users understand the issue.

Comment 10

[Kai Engert [:KaiE:]]

Attachment: 1944810-success.png

This message is shown when a test passes.

Comment 11

[Kai Engert [:KaiE:]]

Tomorrow I will attach a screenshot of an example failure message.

Comment 12

[Kai Engert [:KaiE:]]

Explanation for the dialog that would inform the user about a problem with the selected certificate.

I would like to show 2 sentences plus a human readable error code.
The first sentence would say:
The Certificate verification failed with the following error:

It would be followed by a human readable explanation of the encountered error.
We have a long list of possible problems, where each has its own error explanation, and those strings are localized.
They can be found here:
https://searchfox.org/mozilla-central/source/security/manager/locales/en-US/chrome/pipnss/nsserrors.properties

Most likely we'd get one of the errors that start with SEC_ERROR_, for example
"The certificate issuer’s certificate has expired. Check your system date and time."

Because these strings are localized, if a user reports the localized message to us, it would be difficult for us to immediately understand what the error scenario was. But being able to do that is a central motivation for this work.

Because of that, I propose to also include the human readable error code. (This follows what Firefox does when it reports an error with a site's certificate.)

So I'd suggest this style:

The Certificate verification failed with the following error: The certificate issuer’s certificate has expired. Check your system date and time. (Error code: SEC_ERROR_EXPIRED_ISSUER_CERTIFICATE)

Comment 13

[Kai Engert [:KaiE:]]

Attachment: 1944810-sample-failure.png

Comment 14

[Kai Engert [:KaiE:]]

Attachment: 1944810-success-sig.png

Comment 15

[Kai Engert [:KaiE:]]

Attachment: 1944810-success-enc.png

Comment 16

[LaurelT]

Your proposed UI solve with the 2 test buttons works, along with displaying a success message relevant to either signing or encryption.

You've also covered error / failure states with clear feedback to the user.

Everything looks good by me.

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/ebddc1615dae
Allow testing of a configured personal S/MIME certificate and display the reason when it's unusable. r=mkmelin