# SSL/TLS errors on very old browsers connecting to Discourse
**URL:** https://meta.discourse.org/t/ssl-tls-errors-on-very-old-browsers-connecting-to-discourse/127474
**Category:** Support
**Created:** [9월 3, 2019, 9:11오전 UTC](https://meta.discourse.org/t/ssl-tls-errors-on-very-old-browsers-connecting-to-discourse/127474 "2019-09-03T09:11:06Z")
**Posts on this page:** 19
**Page:** 1
### Author:  [@joa](https://meta.discourse.org/u/joa)
#### Post date: [9월 3, 2019, 9:11오전 UTC](https://meta.discourse.org/t/ssl-tls-errors-on-very-old-browsers-connecting-to-discourse/127474/1 "2019-09-03T09:11:07Z")
After setting up my Discourse instance using the default Let’s Encrupt support, I got reports from some of my users that their browser can’t establish a secure connection to Discourse. One screenshot I got from a user clearly points to an SSL/TLS error. It’s a browser-side error and the users don’t even see anything from Discourse.
Judging by the context those users seem to have somewhat older operating systems/browsers. I first suspected TLS 1.2 support to be the issue, but the user I checked with is running Safari 10.1.2 on macOS (unknown version) and according to [Can I use... Support tables for HTML5, CSS3, etc](https://caniuse.com/#feat=tls1-2) Safari should be supporting TLS 1.2 since version 7.
Is there another reason except for TLS 1.2, which would cause a browser/operating system to fail to establish a secure connection to a default Discourse installation using the default TLS support via Let’s Encrypt? I’m trying to figure out what questions I should ask of my users to figure out what their issue is and on what end it should be fixed.
As a workaround: Afaict, the default is to redirect the traffic going to `http` to `https`. Is there a way to do a check first, something like “only if Browser supports TLS 1.2” or “only if Browser/OS greater than version”, otherwise stay with `http`?
This is the URL, in case you have an idea how to check whether something is incorrectly configured: [https://forum.stadtteilgenossenschaft-wik.de](https://forum.stadtteilgenossenschaft-wik.de)
---
### Author:  [@gerhard](https://meta.discourse.org/u/gerhard)
#### Post date: [9월 3, 2019, 11:28오전 UTC](https://meta.discourse.org/t/ssl-tls-errors-on-very-old-browsers-connecting-to-discourse/127474/2 "2019-09-03T11:28:53Z")
You can test your site using the [SSL Server Test](https://www.ssllabs.com/ssltest). The test results contain a section named “Handshake Simulation” which should show you browser/OS combinations that work / do not work.
With the latest Docker image I’m seeing the following TLS configuration:
You can send your users to [https://www.ssllabs.com/ssltest/viewMyClient.html](https://www.ssllabs.com/ssltest/viewMyClient.html) in order to get more information about their browser and OS versions as well as supported TLS versions.
---
### Author:  [@joa](https://meta.discourse.org/u/joa)
#### Post date: [9월 3, 2019, 6:42오후 UTC](https://meta.discourse.org/t/ssl-tls-errors-on-very-old-browsers-connecting-to-discourse/127474/3 "2019-09-03T18:42:06Z")
Thank you for the detailed response!
I ran the SSL Server Test and can’t find anything wrong with the result:
> **[SSL Server Test: forum.stadtteilgenossenschaft-wik.de (Powered by Qualys SSL...](https://www.ssllabs.com/ssltest/analyze.html?d=forum.stadtteilgenossenschaft-wik.de&hideResults=on)**
They are the same as the ones in your post, afaict.
The only failures were for old OS+Safari version (Safari 8+9) and old windows versions with IE 11. That last one concerns me a bit: shouldn’t IE 11 be supported by Discourse and also support TLS 1.2 by default?
The test also doesn’t contain a test for Safari 10 on the oldest still supported OS, so maybe that also fails…
---
### Author:  [@supermathie](https://meta.discourse.org/u/supermathie)
#### Post date: [9월 3, 2019, 6:51오후 UTC](https://meta.discourse.org/t/ssl-tls-errors-on-very-old-browsers-connecting-to-discourse/127474/4 "2019-09-03T18:51:36Z")
For those users on old Windows versions, you probably need to enable the CBC ciphers:
The very next thing you should do is send those users to
> [@gerhard](#):
>
> [Qualys SSL Labs - Projects / SSL Client Test](https://www.ssllabs.com/ssltest/viewMyClient.html)
to get information about what their browser supports. The easiest way to share their result is _probably_ having them print to a PDF and send it to you.
---
### Author:  [@joa](https://meta.discourse.org/u/joa)
#### Post date: [9월 5, 2019, 8:31오후 UTC](https://meta.discourse.org/t/ssl-tls-errors-on-very-old-browsers-connecting-to-discourse/127474/5 "2019-09-05T20:31:21Z")
Thank you, I got a response from my user. They are using a very old iPod Touch:
> SSL/TLS Capabilities of Your Browser
> **User Agent:** Mozilla/5.0 (iPod; CPU iPhone OS 6\_1\_6 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10B500 Safari/8536.25
>
> # Protocol Support
>
> Your user agent has good protocol support.
>
> Your user agent supports TLS 1.2, which is recommended protocol version at the moment.
So while it’s old (and I’m aware that it’s far away from Discourse‘s minimum supported OS+browser) I‘d like to enable them to a least connect to the site and see how their browser fares with the modern HTML and JavaScript.
This is the detailed TLS support report:
> # Protocol Features
>
> 
>
> ### Protocols
>
> TLS 1.3 No
> TLS 1.2 Yes
> TLS 1.1 Yes
> TLS 1.0 Yes
> SSL 3 Yes
> SSL 2 No
>
> 
>
> ### Cipher Suites (in order of preference)
>
> TLS\_EMPTY\_RENEGOTIATION\_INFO\_SCSV ( `0xff` ) -
> TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_CBC\_SHA384 ( `0xc024` ) **WEAK** 256
> TLS\_ECDHE\_ECDSA\_WITH\_AES\_128\_CBC\_SHA256 ( `0xc023` ) **WEAK** 128
> TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_CBC\_SHA ( `0xc00a` ) **WEAK** 256
> TLS\_ECDHE\_ECDSA\_WITH\_AES\_128\_CBC\_SHA ( `0xc009` ) **WEAK** 128
> TLS\_ECDHE\_ECDSA\_WITH\_RC4\_128\_SHA ( `0xc007` ) **INSECURE** 128
> TLS\_ECDHE\_ECDSA\_WITH\_3DES\_EDE\_CBC\_SHA ( `0xc008` ) **WEAK** 112
> TLS\_ECDHE\_RSA\_WITH\_AES\_256\_CBC\_SHA384 ( `0xc028` ) **WEAK** 256
> TLS\_ECDHE\_RSA\_WITH\_AES\_128\_CBC\_SHA256 ( `0xc027` ) **WEAK** 128
> TLS\_ECDHE\_RSA\_WITH\_AES\_256\_CBC\_SHA ( `0xc014` ) **WEAK** 256
> TLS\_ECDHE\_RSA\_WITH\_AES\_128\_CBC\_SHA ( `0xc013` ) **WEAK** 128
> TLS\_ECDHE\_RSA\_WITH\_RC4\_128\_SHA ( `0xc011` ) **INSECURE** 128
> TLS\_ECDHE\_RSA\_WITH\_3DES\_EDE\_CBC\_SHA ( `0xc012` ) **WEAK** 112
> TLS\_ECDH\_ECDSA\_WITH\_AES\_256\_CBC\_SHA384 ( `0xc026` ) **WEAK** 256
> TLS\_ECDH\_ECDSA\_WITH\_AES\_128\_CBC\_SHA256 ( `0xc025` ) **WEAK** 128
> TLS\_ECDH\_RSA\_WITH\_AES\_256\_CBC\_SHA384 ( `0xc02a` ) **WEAK** 256
> TLS\_ECDH\_RSA\_WITH\_AES\_128\_CBC\_SHA256 ( `0xc029` ) **WEAK** 128
> TLS\_ECDH\_ECDSA\_WITH\_AES\_128\_CBC\_SHA ( `0xc004` ) **WEAK** 128
> TLS\_ECDH\_ECDSA\_WITH\_AES\_256\_CBC\_SHA ( `0xc005` ) **WEAK** 256
> TLS\_ECDH\_ECDSA\_WITH\_RC4\_128\_SHA ( `0xc002` ) **INSECURE** 128
> TLS\_ECDH\_ECDSA\_WITH\_3DES\_EDE\_CBC\_SHA ( `0xc003` ) **WEAK** 112
> TLS\_ECDH\_RSA\_WITH\_AES\_128\_CBC\_SHA ( `0xc00e` ) **WEAK** 128
> TLS\_ECDH\_RSA\_WITH\_AES\_256\_CBC\_SHA ( `0xc00f` ) **WEAK** 256
> TLS\_ECDH\_RSA\_WITH\_RC4\_128\_SHA ( `0xc00c` ) **INSECURE** 128
> TLS\_ECDH\_RSA\_WITH\_3DES\_EDE\_CBC\_SHA ( `0xc00d` ) **WEAK** 112
> TLS\_RSA\_WITH\_AES\_256\_CBC\_SHA256 ( `0x3d` ) **WEAK** 256
> TLS\_RSA\_WITH\_AES\_128\_CBC\_SHA256 ( `0x3c` ) **WEAK** 128
> TLS\_RSA\_WITH\_AES\_128\_CBC\_SHA ( `0x2f` ) **WEAK** 128
> TLS\_RSA\_WITH\_RC4\_128\_SHA ( `0x5` ) **INSECURE** 128
> TLS\_RSA\_WITH\_RC4\_128\_MD5 ( `0x4` ) **INSECURE** 128
> TLS\_RSA\_WITH\_AES\_256\_CBC\_SHA ( `0x35` ) **WEAK** 256
> TLS\_RSA\_WITH\_3DES\_EDE\_CBC\_SHA ( `0xa` ) **WEAK** 112
> TLS\_DHE\_RSA\_WITH\_AES\_128\_CBC\_SHA256 ( `0x67` ) **WEAK** 128
> TLS\_DHE\_RSA\_WITH\_AES\_256\_CBC\_SHA256 ( `0x6b` ) **WEAK** 256
> TLS\_DHE\_RSA\_WITH\_AES\_128\_CBC\_SHA ( `0x33` ) **WEAK** 128
> TLS\_DHE\_RSA\_WITH\_AES\_256\_CBC\_SHA ( `0x39` ) **WEAK** 256
> TLS\_DHE\_RSA\_WITH\_3DES\_EDE\_CBC\_SHA ( `0x16` ) **WEAK** 112
> TLS\_ECDHE\_ECDSA\_WITH\_NULL\_SHA ( `0xc006` ) **INSECURE** 0
> TLS\_ECDHE\_RSA\_WITH\_NULL\_SHA ( `0xc010` ) **INSECURE** 0
> TLS\_ECDH\_ECDSA\_WITH\_NULL\_SHA ( `0xc001` ) **INSECURE** 0
> TLS\_ECDH\_RSA\_WITH\_NULL\_SHA ( `0xc00b` ) **INSECURE** 0
> TLS\_RSA\_WITH\_NULL\_SHA256 ( `0x3b` ) **INSECURE** 0
> TLS\_RSA\_WITH\_NULL\_SHA ( `0x2` ) **INSECURE** 0
> TLS\_RSA\_WITH\_NULL\_MD5 ( `0x1` ) **INSECURE** 0
> (1) When a browser supports SSL 2, its SSL 2-only suites are shown only on the very first connection to this site. To see the suites, close all browser windows, then open this exact page directly. Don’t refresh.
>
> 
>
> ### Protocol Details
>
> Server Name Indication (SNI) Yes
> Secure Renegotiation Yes
> TLS compression No
> Session tickets No
> OCSP stapling No
> Signature algorithms SHA384/RSA, SHA256/RSA, SHA1/RSA, SHA256/ECDSA, SHA1/ECDSA
> Named Groups secp256r1, secp384r1, secp521r1
> Next Protocol Negotiation No
> Application Layer Protocol Negotiation No
> SSL 2 handshake compatibility No
>
> ### Mixed Content Handling
>
> 
>
> Mixed Content Tests
> Images Passive Yes
> CSS Active Yes
> Scripts Active Yes
> XMLHttpRequest Active Yes
> WebSockets Active Yes
> Frames Active Yes
> (1) These tests might cause a mixed content warning in your browser. That’s expected.
> (2) If you see a failed test, try to reload the page. If the error persists, please get in touch.
Sorry about the formatting, the user copy-pasted the rich text HTML for me and some of it gets lost when pasting to Discourse. I’ll try to figure out how to fix the formatting later.
As I said, I’d like to enable them to at least establish a secure connection so they’ll see _something_ and it should be possible as the browser supports TLS 1.2. But I guess I’d have to enable some less-secure config for TLS 1.2 for their browser to be supported. I don’t know enough about TLS condors to match the output of that report to what the server supports and what I’d have to change. Can you tell me what’s missing and what I’d have to change?
---
### Author:  [@joa](https://meta.discourse.org/u/joa)
#### Post date: [9월 5, 2019, 8:33오후 UTC](https://meta.discourse.org/t/ssl-tls-errors-on-very-old-browsers-connecting-to-discourse/127474/6 "2019-09-05T20:33:58Z")
> [@supermathie](#):
>
> you probably need to enable the CBC ciphers:
I have a rough idea what you mean, but I have no clue how to do that. Can you point me to some documentation that explains how to change the TLS config of the Discourse Docker container to enable these?
---
### Author:  [@gerhard](https://meta.discourse.org/u/gerhard)
#### Post date: [9월 7, 2019, 12:13오전 UTC](https://meta.discourse.org/t/ssl-tls-errors-on-very-old-browsers-connecting-to-discourse/127474/7 "2019-09-07T00:13:36Z")
> [@joa](#):
>
> **User Agent:** Mozilla/5.0 (iPod; CPU iPhone OS 6\_1\_6 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10B500 Safari/8536.25
I don’t think Safari 6 will work even when you solve the TLS issues by adding additional cipher suites.
You can add missing cipher suites by overriding the nginx config file. Add the following snippet (untested, but it should work) to the `hooks` section of `app.yml` and change the value of `ssl_ciphers` to your liking.
```plaintext
after_ssl:
- replace:
filename: "/etc/nginx/conf.d/discourse.conf"
from: /ssl_ciphers .*/
to: ssl_ciphers ;
```
BTW: I’m trying to add support for Elliptic Curve certificates to Discourse which would make it work for IE11 out of the box.
[https://github.com/discourse/discourse\_docker/pull/444](https://github.com/discourse/discourse_docker/pull/444)
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [9월 7, 2019, 6:38오전 UTC](https://meta.discourse.org/t/ssl-tls-errors-on-very-old-browsers-connecting-to-discourse/127474/8 "2019-09-07T06:38:29Z")
iOS 6?! The last version of that was released in early 2014! That was more than 5 years ago!
> **[iOS 6](https://en.wikipedia.org/wiki/IOS_6)**
>
> iOS 6 is the sixth major release of the iOS mobile operating system developed by Apple Inc., being the successor to iOS 5. It was announced at the 2012 Worldwide Developers Conference on June 11, 2012, and was released on September 19, 2012. It was succeeded by iOS 7 on September 18, 2013. It was also the last iOS major release to feature a skeuomorphic design, as iOS 7 would introduce a completely new flat design overhaul.
> iOS 6 introduced Apple Maps, which replaced Google Maps as the defa...
---
### Author:  [@joa](https://meta.discourse.org/u/joa)
#### Post date: [9월 7, 2019, 6:48오전 UTC](https://meta.discourse.org/t/ssl-tls-errors-on-very-old-browsers-connecting-to-discourse/127474/9 "2019-09-07T06:48:21Z")
I know, I was as surprised as you are. I don’t expect you to support it, but I’d want the user to get at least some HTML and see what works and what doesn’t.
---
### Author:  [@joa](https://meta.discourse.org/u/joa)
#### Post date: [9월 8, 2019, 9:07오전 UTC](https://meta.discourse.org/t/ssl-tls-errors-on-very-old-browsers-connecting-to-discourse/127474/10 "2019-09-08T09:07:06Z")
Thank you @gerhard, I made the change you described to `/var/discourse/containers/app.yml` (hope that was the correct app.yml file) and then ran `/var/discourse/launcher rebuild app` as described in the comments of `app.yml`.
I then reran the test on [ssllabs.com](http://ssllabs.com), but it seems like the result didn’t change: [SSL Server Test (Powered by Qualys SSL Labs)](https://www.ssllabs.com/ssltest/analyze.html?d=forum.stadtteilgenossenschaft%2dwik.de&s=68.183.214.228&hideResults=on)
I’m not sure how to verify whether the config change actually worked (but it didn’t influence the test result) or whether the config change didn’t work.
---
### Author:  [@joa](https://meta.discourse.org/u/joa)
#### Post date: [9월 9, 2019, 6:43오후 UTC](https://meta.discourse.org/t/ssl-tls-errors-on-very-old-browsers-connecting-to-discourse/127474/11 "2019-09-09T18:43:15Z")
oh, I didn’t read your post properly @gerhard. If I understand it correctly, the config you provided will make the used ciphers explicit but the value you used is basically the same as the default right? So I’d have to still extend it with other ciphers that might be supported by older browsers.
---
### Author:  [@gerhard](https://meta.discourse.org/u/gerhard)
#### Post date: [9월 9, 2019, 6:54오후 UTC](https://meta.discourse.org/t/ssl-tls-errors-on-very-old-browsers-connecting-to-discourse/127474/12 "2019-09-09T18:54:40Z")
Yes, exactly. I didn’t want to post a solution for adding weak ciphers to the config. You’ll have to figure this out yourself. 😉
But if you are making those changes I’d keep an eye on the pull request I mentioned earlier. If it gets merged IE11 will work out of the box.
---
### Author:  [@joa](https://meta.discourse.org/u/joa)
#### Post date: [9월 9, 2019, 7:30오후 UTC](https://meta.discourse.org/t/ssl-tls-errors-on-very-old-browsers-connecting-to-discourse/127474/13 "2019-09-09T19:30:53Z")
I see, you don’t want to make it too easy for someone to make their setup insecure. I respect that and will also not post the complete code.
Here’s what I got so far: I identified the cipher suites that are missing to support older browsers/OSs by looking at e.g. [Qualys SSL Labs - Projects / User Agent Capabilities: Safari 6 / iOS 6.0.1](https://www.ssllabs.com/ssltest/viewClient.html?name=Safari&version=6&platform=iOS%206.0.1&key=33) (and for others as well). As the client cipher suites are listed by preference I just always picked the topmost one and made sure I’m supporting it, assuming that if the server supports one from the list, that should be sufficient. Here are the ciphers I identified:
- `ECDHE-ECDSA-AES256-CBC-SHA384` for Safari 6-8
- `ECDHE-RSA-AES256-CBC-SHA384` for IE 11 on Win 7/8.1/Phone 8.1 Update (according to @supermathie)
- `ECDHE-RSA-AES128-CBC-SHA256` for IE 11 on Win Phone 8.1
I took these values and added them to the end of the list of `ssl_ciphers`, separated by colons, assuming that “end of the list” means “least preferred, will only be used if client doesn’t support anything else”. I then ran `/var/discourse/launcher rebuild app` to apply the new config and reran the test on [SSL Server Test: forum.stadtteilgenossenschaft-wik.de (Powered by Qualys SSL Labs)](https://www.ssllabs.com/ssltest/analyze.html?d=forum.stadtteilgenossenschaft%2dwik.de&s=68.183.214.228&hideResults=on&latest) after clearing the cache. But the results didn’t change.
I expected it to now be successful both for the failing IE 11 tests as well as Safari 6-8, but the handshake still fails. So I must be missing something.
Also, one of my users is using an iPhone with iOS 9/Safari 9 and for them the connection also fails. But according to the test results of SSL Labs, that connection should already work out of the box (as is also visible in [@gerhard’s result above](https://meta.discourse.org/t/ssl-tls-errors-on-very-old-browsers-connecting-to-discourse/127474/2)).
So I must be missing two things:
1. Why is the connection still not working after adding support for the ciphers?
2. Why does SSLLabs says it works for iOS 9 + Safari 9 but it doesn’t actually work for my user?
Regarding 1: I’m still not sure I applied the config correctly. Apart from the SSL Labs Test, is there another way to check which ciphers the server supports to see whether my config change was actually applied correctly?
---
### Author:  [@joa](https://meta.discourse.org/u/joa)
#### Post date: [9월 9, 2019, 7:49오후 UTC](https://meta.discourse.org/t/ssl-tls-errors-on-very-old-browsers-connecting-to-discourse/127474/14 "2019-09-09T19:49:07Z")
After looking it the SSLLab result more closely, I _think_ this doesn’t work.
This is the result I see on SSLLabs for my server after applying the config and rebuilding:
According to my understanding, it should list many more, as the config has many more options. Does this mean this config change didn’t work?
---
### Author:  [@gerhard](https://meta.discourse.org/u/gerhard)
#### Post date: [9월 9, 2019, 8:58오후 UTC](https://meta.discourse.org/t/ssl-tls-errors-on-very-old-browsers-connecting-to-discourse/127474/15 "2019-09-09T20:58:11Z")
I think the ciphers you chose have the wrong names. [Mapping OpenSSL cipher suite names to IANA names](https://testssl.sh/openssl-iana.mapping.html) is a good resource for mapping between the ciphers listed by the SSL Server Test and the names used by OpenSSL (nginx).
In my tests I appended `:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA` and after a rebuild the test looks like this:
> [@joa](#):
>
> Why does SSLLabs says it works for iOS 9 + Safari 9 but it doesn’t actually work for my user?
Maybe there’s a bug in the test? 🤷♂️ I don’t have such an old Safari for testing. We support only Safari 10+. Are you sure that it still fails due to a TLS error?
---
### Author:  [@joa](https://meta.discourse.org/u/joa)
#### Post date: [9월 9, 2019, 9:09오후 UTC](https://meta.discourse.org/t/ssl-tls-errors-on-very-old-browsers-connecting-to-discourse/127474/16 "2019-09-09T21:09:22Z")
Thank you, will try that!
I looked through the Discourse config files a bit more and found `templates/web.ssl.template.yml`. What’s the difference between making this change to the ciphers via the app.yml file and just changing the list of `ssl_ciphers` in `templates/web.ssl.template.yml` directly?
---
### Author:  [@gerhard](https://meta.discourse.org/u/gerhard)
#### Post date: [9월 9, 2019, 9:14오후 UTC](https://meta.discourse.org/t/ssl-tls-errors-on-very-old-browsers-connecting-to-discourse/127474/17 "2019-09-09T21:14:43Z")
> [@joa](#):
>
> What’s the difference between making this change to the ciphers via the app.yml file and just changing the list of `ssl_ciphers` in `templates/web.ssl.template.yml` directly?
The template is version controlled and the `app.yml` is not. You’ll have problems updating the repository when you edit the template.
---
### Author:  [@joa](https://meta.discourse.org/u/joa)
#### Post date: [9월 9, 2019, 9:19오후 UTC](https://meta.discourse.org/t/ssl-tls-errors-on-very-old-browsers-connecting-to-discourse/127474/18 "2019-09-09T21:19:46Z")
> [@gerhard](#):
>
> I think the ciphers you chose have the wrong names. [Mapping OpenSSL cipher suite names to IANA names](https://testssl.sh/openssl-iana.mapping.html) is a good resource for mapping between the ciphers listed by the SSL Server Test and the names used by OpenSSL (nginx).
Thank you this was the issue and fixing the names makes the handshake work for all browsers tested in the list of SSLLabs. Thank you so much for your patience!
Now, I’m interested to learn what my users are seeing once they got past the HTTPS error with their old browsers. 😃
---
### Author:  [@system](https://meta.discourse.org/u/system)
#### Post date: [10월 9, 2019, 9:19오후 UTC](https://meta.discourse.org/t/ssl-tls-errors-on-very-old-browsers-connecting-to-discourse/127474/19 "2019-10-09T21:19:54Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.