SSL problem on Sutta Central

Some users have posted at DhammaWheel that they are having difficulty using Sutta Central. The error message some get is:

I don’t have this problem, so I can’t really elaborate…


Speaking perhaps like a business analyst, a primer off the top of my head:

Different browser distributions will have different SSL certificates preinstalled on them. Each certificate is part of a tree or chain of certificates.

Warnings occur when a certificate’s “ancestry” is incompatible.

Here I’ve been out of the loop somewhat on that free SSL service and the WikiLeaks revelations and updates to best-practice encryption algorithms so perhaps a user like @Ataraxia_Now with that bright red fedora as profile picture might be able to comment?

Thanks for the heads up. @blake, can you look into this?

It is known there are some browsers that will not work with cloudflare because they have outdated certificates. Unfortunately other than not using cloudflare and instead using widely supported certificate (which may mean using outdated encryption) there’s not too much which can be done. An example I know of is Android 2.x browsers - actually it is probably more a matter of operating system than browser.

Another known offender is antivirus software which likes to insert itself as man in the middle of SSL connections so it can check for dodgy content. If the antivirus does not have the proper certificates it produces that same error.

Thanks Blake. @mikenz66, if people are still reporting issues, could you ask them to report directly to us? There’s not much we can do without knowing the details.

I’ll copy these replies. The problem is that if they can’t connect they can’t report. It’s a bit circular…


In this case it’s probably caused by an OS which hasn’t been updated for a while, browsers usually rely on the OS for TLS so changing browser doesn’t change anything. Antiviruses are more invasive and so can embed themselves deeper in the OS and hijack the TLS. In fact the error on the dhammawheel first post looks a lot like this:

The client and server don’t support a common SSL protocol or cipher suite. This is likely to be caused when the server needs RC4, which is no longer considered secure.

My conjecture would be that an antivrus has inserted itself into TLS and wants an RC4 connection, the browser says “no way that’s insecure”, because the browser is talking to the antivirus it thinks the antivirus is the server. The browser refuses to communicate further. It’s also possible that it’s not an antivirus but another kind of man the middle “defender”, such as a SSL snooping firewall as is sometimes found in corporations, schools and some ISPs. A (modern) browser is perfectly able to detect this subterfuge and if the connection is not allowed to be “downgraded” (forcing a less secure connection is the usual strategy employed by these firewalls) then the connection attempt will be aborted because it cannot provide the promised security level (that is, that no-one along the way can snoop on the traffic).

1 Like

Do you mean they can’t reach here, on Discourse, or on the main site? Because these are two completely different platforms.

So it’s like when the Empire built a whole new Death Star but forgot to take Ewoks into account. Anyway, that’s what I understood!

1 Like

Thanks, @Blake I’ve relayed that. By “not updated” do you mean someone with, say, Windows 7 (or earlier…) and no service packs?

Hmm, I’ll ask them. But if you use the same SSL on both platforms wouldn’t they have the same problem?

Maybe! But it never hurts to eliminate variables. Anyway, we have you: like the gatekeeper in MN 56, you’re the real hero of the story.

1 Like

This is where myths are made, eh?

I fancied myself as a relay chariot, actually. Or a “Trained Chariot”. :slight_smile:

1 Like

heh Red Hat to be precise, but that’s legacy now. Greetings​

1 Like

I’m mainly on Android tablet these days… So ROM isn’t flashable. Greetings my friend, I don’t think I can help

1 Like

Yeah, an old operating system and updates disabled would be a good recipe. A while ago I discovered the issue on an old android phone. I was like “oh well, that’s the steamroller of obsolescence for you”, that particular device was too primitive to be updated to a newer OS and Google eventually stops supporting older software as a matter of policy. Windows 7 should be fine though older versions of XP can have problems with modern encryption.

Actually it’s likely to be an issue with cloudflare hosted sites in general, since the connection goes to Cloudflare (from the browser’s perspective, the connection ends at a Cloudflare server, it’s irrelevant that behind Cloudflare the two subdomains are hosted at different servers). Users of low-cost Cloudflare plans get shared certificates, business users can use their own certificate and can also get Cloudflare to support old devices (with compromised security), so it’s not the case that all sites served via Cloudflare will have the same certificate issues, just those on the free/pro plans.

It should be noted that it’s not just a thing with Cloudflare: If you use Lets Encrypt you’d run into much the same issue. A certificate provider which only supports modern encryption will not support old devices/OS’s.


To be clear of course, ROM most probably wouldn’t be flashable without wired connection.
Would you concur? :spy:

I say because a premise like that would be a perfectly reasonable avenue of attack if one were to have say a BILLION dollars and a bunch of dumb ideas would it not? :golfer:

If my memory is right (it’s been 25+yrs) if CMOS was getting stuck,you’d remove the battery and wait to drain out. That would reset it. But to flush it, hmmm, it has to have a connection of some sorts to the new software. Early chips (industrial, non PC) would have an optic opening so you can send/blow the new code that way. Latter days, on PC, it was done directly from HD, the portion that it can see, or was it floppy? But it would have to be thru’ a proprietary driver. How it’s done today, I do not know. It wouldn’t surprise me if they force you to buy a new one, preloaded with a new code. Silicon is cheap.

On macOS, using Firefox, my SSL “padlock” shows a warning that not all parts of the page are secure via the SSL certificate. This is usually because of objects that are being pulled in from somewhere other than the server that has the certificate, like images. However:

On Windows 10, using Firefox, SSL is fine. On Vivaldi, SSL is connected for the main Discuss and Discover page, but breaks as soon as I click into a discussion thread. On macOS using Safari, the connection stays secure. I can check various browsers on Linux later today if anyone would like a report on that.

I suspect that importing the site’s certificate into the browser or OS (depending on which is handling it) would solve the problem for everyone. I’ve done that successfully with self-signed certificates at work.

1 Like

Yes, this is an open issue:

It is doable, Discourse forums with lots more images than us still validate: