Windows Live Mail revocation warning

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?

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.

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.


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.

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.


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

And @pfg maybe know who to ping to update ?

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

I opened for this.

Thanks everyone!

1 Like

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

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?

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…

1 Like

(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.

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.

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.

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?

1 Like

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!

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.

Probably because there is not anything what could be done from Let’s Encrypts end ánd probably nothing to be done about it on the client end… In any case, not anything we can think of… Otherwise you would have heard it already :slight_smile:

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.

They aren’t aware they are “connecting to our site”. They’re just pictures in an email, as far as they are concerned, and everyone else’s pictures work.

No, of course they won’t disable checking, they’ll just delete the emails unread and report them as spam.

You asked for a solution. That is a solution. If thát doesn’t work for you, how would any other client-side workaround work for you?

As said, there is most certainly absolutely nothing Let’s Encrypt can do about this from their end. Or at least nothing feasible.