Comment 74 for bug 239360

As I said earlier, the patch checked in today only works for https and some random ports.

It does not yet work for mail server ports, although the solution was intended to be generic across protocols.

Currently we use xmlhttprequest for cert-from-ssl-connection fetching, but this implementation blocks many ports, including all mail server ports.

It was already clear that we'd need a generic service for fetching the server cert from a ssl connection, that would work with any port.

But when I started to work on that today, I realized, it's more complicated!

In addition to connection of the style:
  cleartext-protocol-completely-wrapped-in-ssl

there is also the mechanism known as STARTTLS, which works like:
  plaintext-phase-then-switch-to-ssl

The trouble is, the initial plaintext-phase isn't universal, for example, IMAP-STARTTLS and SMTP-STARTTLS use a different plaintext-phase.

This means, we can't use a single generic implementation for fetching the server ssl certificate from a protocol specific connection. We'd have to bring the server configuration details, and we'd have to make use of the protocol specific application code for starting the connection.

Maybe we will have to do this. But it seems complicated, might require tricky UI and might non-trivial code to be written.

After scratching my head, I came up with a workaround approach. It's not perfect, but I think it's a reasonable workaround.

I already implemented it. It's attached as "Non-Web Patch v2". Let me explain what it does.

Whenever we encounter a "bad cert" (expired, untrusted, mismatch), PSM will remember it. Actually, PSM will remember a couple of recently-seen-bad-certs, and will remember to which hostname and port it was associated, as well as the verification result.

These certs will not be stored on disk. Not imported into the NSS database. But they will be available to be retrived using a new service: nsIRecentBadCertsService

This list of recently-seen-bad-certs will not shown to the user, only available internally.

However, we can make use of this list while executing the add-exception dialog.

In a typical session the user might configure a new smtp mail server that requires STARTTLS The connection will fail and an error dialog will be shown (e.g. can't connect, mail.somewhere.org:25 uses expired cert).

PSM will remember that cert.

Now the educated user will have to know where to go. He will open cert manager and find the add-exception button. He will enter mail.somewhere.org:25 into the location field.

Now the add-exception-dialog will query the nsIRecentBadCertsService with the key mail.somewhere.org:25
The cert will get returned with the expiration status.
The dialog can display the cert status and offer to add the override.

Whenever the add-exception dialog gets a matching cert+status from nsIRecentBadCertsService, it can avoid to call into xmlhttprequest (which is blocked and therefore nonworking for port number 25).

This means: Before an override can be added (for mail ports), the user must try to connect to the server once. Only afterwards will an attempt to add an exception work.

I think this is a reasonable and simple intermediate solution, and I propose to check it in until we have something better.

The thunderbird trunk testers will be thankful (because right now, with the landing of bug 327181, the use of servers with bad certs is completely impossible).