Windows Live Mail revocation warning

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.

Most users of LetsEncrypt, apparently all except you, don’t care about this feature.

Well, the reason I'm raising it is because it has relevance for more than just me. It took us nearly a year before anyone even bothered telling us that this was a problem - most of the time, as I said, people just move on elsewhere. I suspect many people using images in email have the same problem, just don't know it because none of their recipients has pointed it out to them. Now I know about it, I can indeed tell people that there is a setting they can change, though it seems to be "turn off all images from everyone" from what I can see so far, which won't go down well either. I doubt most people using MS Live Mail know that it is obsolete.

...absolutely nothing Let's Encrypt can do about this...

I understand the problem is not directly solvable, but for example, an approach to Microsoft is something LE could do that wouldn't have an effect if it came from me. I can certainly try, but they will just say "unsupported, unsupported".

The XP issue was also effectively deemed "impossible to solve" when it was first raised! I'm not looking for miracles, but this is a genuine problem. It may be small in percentage terms, but there must still be millions of active Live mail users out there, for whom images work in emails except where the sender uses a LE certificate.

1 Like

Microsoft is pretty stubborn when it comes to fixing things in products that aren't supported anymore. Probably rightfully so - Pandora's box and all that. I doubt this will be successful no matter who asks, especially since - from Microsoft's perspective - workarounds (like using a CA with CRL support) exist.

I don't think this is accurate. From what I recall, this is the first statement regarding XP support. Again, there's no similar solution here, so there's really nothing Let's Encrypt can do, other than document the issue (which has happened).

1 Like

How do CRL and OCSP interact? If they are both indicated are they both checked, or does one take precedence? If OCSP is overwhelmingly used, is bandwidth a big deal, as it would only then be old clients that would be asking? Why don’t all CA’s have this issue - or do they, but they are large enough to cope and can fund it because people pay for certificates? What happens in browsers if a CRL doesn’t respond but OCSP does? Might that offer a route by which a CRL responder only works for the low-volume cases that can’t be solved by OCSP, and therefore reduces the overhead to very small?

Hi @fas,

Thanks for checking in again on this issue. It probably is possible to fix this issue by implementing CRL. It would require a substantive investment in engineering time even to reproduce the issue and verify that providing CRL fixes. It would require significantly more engineering and ops time to design and build a CRL system for our end-entity certificates, and maintain it over the long term.

While I empathize with your issue, and would like to make Let’s Encrypt as broadly compatible as possible, I do have to balance costs and benefits. In this case, the cost of implementing CRL is very high, and the benefit-- supporting an older mail client with relatively low usage-- is not large enough to justify the cost. If we had evidence showing a large number of people reporting that Windows Live Mail support was a high priority, that balance might shift, but for now we can’t justify the work.

Is buying a certificate from another CA an option for you?

Oh, and I forgot one more option you have: Just serve your images over http instead of https. That used to be the way by the time Outlook Express and Windows Live Mail were great, anyway.

BTW, and if the admins here don’t mind to link to commercial services I’m not affiliated with, I bought a really cheap ($14 for 3 years) Comodo PositiveSSL certificate from gogetssl.com two years ago which contains CRL entries. I’m pretty sure that they still offer this feature. Perhaps their free certificates have it, too, but I cannot tell.

OCSP, especially OCSP Stapling, typically takes precedence because of its better performance. Still, fetching OCSP responses leads to time-outs frequently, so most browsers just don’t care for that by default, even Internet Explorer.

Yes, only old clients are asking for CRL, and they look it up typically only if it’s enabled, or only for EV certificates. Most browsers and other clients have dropped support for it completely, years ago.

But remember, OCSP Stapling is a feature that a server admin can use to improve the availability of the OCSP result to the client as well as overall performance.

Other CAs don’t have the problem because they still support CRLs. Simply as that.

There is nothing that can’t be solved by OCSP which can be solved by CRL. Instead, OCSP offers more features and better performance than CRL altogether, that’s why it is so easy for most of us to switch there without looking back.

They don't, they are independend methods of revocation checking, both with their advantages and disadvantages.

That depends on the client.

Not every client uses OCSP, as OCSP without OCSP stapeling has privacy drawbacks/concerns.[quote="fas, post:26, topic:26310"]
Why don't all CA's have this issue (…)
[/quote]

I expect this is indeed because of financial capabilities and/or less number of certificates. Let's Encrypt is growing fast, because it's free.

Comodo's free certificates are only valid for 90 days (same as LE), and last I checked were only for "trial purposes" and only once per domain. That said, many resellers, including NameCheap (my usual source for paid options like wildcards) have very affordable basic DV certs at a very low cost if you need "legacy" stuff like a CRL for old software.

Likely more because the major commercial entities were around before OCSP when CRL was the only mechanism for checking certificate revocation. They also make very good money from selling certificates, which rebalances the cost equation.

Is buying a certificate from another CA an option for you?

Well, yes, clearly that's an option. Rather defeats the point of LetsEncrypt though!

Another would be to host the images somewhere off our normal website (like flickr perhaps) for this purpose.

Just serve your images over http instead of https.

That is less satisfactory, not just for the obvious reasons, but that Outlook.com (why does it always seem to be Microsoft!) doesn't handle this well - you get mixed content. (GMail handles this much better by proxying them).

I think maybe the best answer short of dealing with the problem directly is to use http image links which redirect to https except for the known problem clients. We still do this for IE8 on XP where SNI is a problem, so that mechanism is in place. The main issue then is for the people preparing the mailshot to understand the issue and not blindly put in URLs to the images straight from the website (i.e. Wordpress media library).

Web clients that report mixed content errors will still consider this a mixed content error (because the initial HTTP fetch could have been snooped on or tampered with). So this is not the ideal plan, in my opinion.

This seems like a nice, simple approach that should work.