Windows Live Mail revocation warning


#1

Hi,

One of the recipients of a mailshot is complaining that Windows Live Mail (2012) (on Windows 10) produces certificate revocation information not available" warnings. I managed to find an old installer and sure enough, if images are not disabled, there are as many warnings as there are images with src="https://… in the message (where the site with the images is protected by a LetsEncrypt certificate), and each one needs a click to dismiss it. It’s a huge pain for them, mostly because of the blocking dialog and repetition. This doesn’t happen with IE11, so it isn’t the system certificate store or mechanism that’s the problem; presumably some aspect of certificate management is being done by Live Mail itself.

Of course, Live Mail is obsolete and no longer supported by MS. However, it doesn’t go down well with people to say “change the email program you’re using” especially when it’s only our own emails that are the problem as far as they are concerned. And it isn’t really that old a program, 2012.

Any ideas? Is there anything that can be updated that might help?

Here’s the repeated warning:


Windows Live Mail revocation warning (continued...)
Windows Live Mail revocation warning (continued...)
Which browsers and operating systems support Let's Encrypt
#2

Turning off “Check for server certificate revocation” in Windows 10 Internet Options stops the warning; but this doesn’t seem like a wise thing to do long term. However, it does suggest there is at least some linkage between what Live Mail is doing and the centralised certificate mechanism in W10.


#3

They use an outdated and un-maintenaid (unsecured) tool … Then disable “Check for server certificate revocation” seems to be the option …


#4

But the problem with doing that is it affects current MS products (IE11 and presumably Edge) and presumably also Chrome which uses MS certificate management. It’s a system-wide setting, not Live Mail specific, so you’d lose revocation protection in pretty much everything except Firefox wouldn’t you?


#5

Using only one unsecured tool break whole security … even in other tools, then … thye good answer seems to be ‘Don’t use a broken and unmaintained tool’

It’s not the year , it’s the unmaintained the point.


#6

Hello @fas,

Let’s Encrypt doesn’t use CRL, that is the reason of the warning message, Let’s Encrypt uses OCSP but seems your mail client wants to check the CRL… I suppose it is time to move on to a new and updated mail client.

Cheers,
sahsanu


#7

Yes, I agree. But it’s not in my control. We are the sender, not the recipients. I have done some analysis of log files this morning, and note that it isn’t just one stick-in-the-mud, there are at least 20 recipients on our mailing list who are using Windows Live Mail 2012, supported or not! We can’t tell who they are or tell them what to do. As far as they are concerned it’s our fault.

Moving email clients is a big job which most people would perceive as of no benefit. I’m not surprised people are reluctant to do it. And I can see from the stats that people would rather just discard the mail than change email clients, or even tell us it is happening! That is a terrible outcome.


#8

It looks like Live Mail is using an outdated system for checking certificate revocation called CRL. IE and other systems using SChanel (Microsoft’s encryption/SSL component) aren’t affected because they use the newer OCSP system and ignore the old and broken CRL system.

Unfortunately, I don’t think there is any fix Let’s Encrypt can do besides moving to support a system that every modern tool more or less ignores.

If you want to continue to serve the images with SSL, you may have to use a legacy certificate authority that still supports the CRL mechanism. An alternative is not serving those images over SSL.


#9

Maybe @mrtux could update Which browsers and operating systems support Let's Encrypt ?

And @pfg maybe know who to ping to update https://letsencrypt.org/docs/certificate-compatibility/ ?


#10

I edited the thread to add an entry in the incompatible list that points back to this thread.

I opened https://github.com/letsencrypt/website/pull/128 for this.

Thanks everyone!


#11

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.


#12

#13

With reference to the following (which has been closed so I can’t add to it)…

We have received yet another complaint today about our emails not working in Windows Live Mail. Is there really nothing that can be done to deal with the underlying problem? Despite lack of support from MS, Windows Live Mail, like Outlook Express before it, isn’t going to disappear any time soon, and it’s much more recent an app than, say, Windows XP where LE didn’t work either when first released.

As far as users are concerned, it is

  • intensely annoying as they get loads of modal pop-ups, one per image, which each have to be dismissed individually
  • it appears to them only our emails are a problem, which isn’t true in general but is the perception
  • they have no idea that it is the images that are the problem - as far as they are concerned, our emails are broken, even though the reality is it is their email app that is out-of-date.

I don’t know much about CRL, but is there maybe some way to make a bridge back from OCSP data to CRL, enough to make the obsolete Live mail program work even if revocation isn’t possible there, or some way we might be able to patch Live Mail. Might an approach to Microsoft be helpful?


#14

I don’t think Let’s Encrypt is going to generate a CRL, just to make sure a single discontinued mail client works? They’ve made a choice to issue only signed OCSP statuses and don’t use CRL’s. So I’m guessing that was a deliberate choice, not something they decided lightly.

The mail client expects these CRL data inside the certificate, which is signed by Let’s Encrypt. Furthermore, it would be insane to generate a CRL without using it for revocation checking! That’s the whole point to a CRL! You can’t expect Let’s Encrypt to maintain a seperate bunch of certificates with a “fake” CRL. That’s probably against the CA/B Forum rules too…

I guess that’s something you should ask MS indeed, but don’t get your hopes up…


#15

(Reopened the original topic and merged the previous posts.)

Compared to OCSP, CRL is quite the bandwidth hog. It’s essentially a file containing a list of all revoked certificates from a particular CA (though some partitioning is possible to improve performance), and every user needs to fetch the whole file. Cloudflare had a blog post on this a few years ago during the Heartbleed fiasco (during which a lot of certificates were revoked). They estimated the bandwidth cost for the revocations of just one CA at about $400,000.

Let’s Encrypt probably has (at least) an order of magnitude more active certificates, so we might be talking about $4M for the next Heartbleed. That’s more than what it costs to run Let’s Encrypt for a year otherwise (about $3M). Even without a similar event, the cost for CRL would be significant - about 25,000 certificates are revoked each month (based on stats from December).

Technical reasons aside, it’s probably simply too costly.


#16

I understand the problems, which is why I was looking for some lateral thinking, a work-round of some kind, not necessarily a complete solution. It may be a “single discontinued email client”, but it is apparently, and to my surprise, still widely used, and it isn’t very old. LE did eventually work to find a solution for XP, which is much older and also obsolete.

Obviously an approach to MS from me is going to be completely ignored - that’s why I was asking, as it would need a much higher level approach than from little me. But even if they would consider making the warning non-modal, or turn off the message altogether as it is just wrong now, it would help.

The biggest problem is that as far as the recipient is concerned, it is our fault that we are sending them extremely annoying email faults! Telling them to change their email client, with all that entails to unknowledgeable people who have long since forgotten their email passwords just makes it worse.


#17

But in that case any solution on the client side would hardly be effective? If the clients are that unknowledgeable, something like a “patch” of “user setting” would possibly be difficult to achieve.


#18

XP compatibility was relatively easy to achieve, requiring only a small change to the intermediate certificate and a key signing ceremony. From what I can tell, rolling out CRL would require significantly more effort (both in terms of development effort and financially).

There doesn’t seem to be an easy fix here on Let’s Encrypt’s end, so I would personally look for workarounds elsewhere, like referencing images via a domain behind a certificate from a CA with CRL support. Perhaps proxying through Cloudflare or Amazon CloudFront (both offer free certificates; CloudFront charges for traffic) would work for you?


#19

At least it’s possible to lead someone through that though, and people are familiar now with updates to software they already have.

This thread is still all about pointing out reasons why it is a hard problem to solve, not what could be done to mitigate it!


#20

I don’t get it. You were told all your options, still you insist on Lets Encrypt to move.

If you need CRL information in your certificate, just buy a certificate with this (outdated) feature. The competition is searching for unique selling points, and backwards compatibility is one of them, so go and pay them the money.

If your clients need to connect to your site using the outdated tool, they can disable the checking, which is not a good idea, security wise, but using the old tool isn’t either.

Most users of LetsEncrypt, apparently all except you, don’t care about this feature. So they either went the way of ignoring their clients’ needs, or their clients just don’t use that kind of outdated tool.

Harsh words spoken, I hope you appreciate the summary of your options, nevertheless.