Using HTTPS, TLSV1 fatal handshake

I implemented https using this walkthrough, and browser clients get https.

There are no errors in the logs as above

But at least one person says that they can’t login anymore. And my scripting agent can no longer read the pages ( though it’s able to read and with no problems).

I’m getting a TLSV1 fatal handshake failure showing in wireshark.

Can someone decode the ssllabs report to let me know what the issue is.

I’m also seeing handshake failures there too

Handshake Simulation
Android 2.3.7   No SNI 2	Server sent fatal alert: handshake_failure
OpenSSL 0.9.8y	Server sent fatal alert: handshake_failure

As an alternative, can I just turn off the redirect from http to https?

Perhaps by commenting out

Are you able to provide a reproducible test case? The description of your error is vague and unhelpful. Is your scripting agent running OpenSSL 0.9.8y or Android 2.3.7?

You followed the let’s encrypt instructions? works fine if you access https. Http doesn’t respond, somehow.

The link you provide gives the site an A+ rating.

Yeah, I disabled the redirect I thought but the site no longer works with http :frowning:

And, yes, I see the A+ rating but I also see fatal handshake errors in the report and I think that’s what is killing my scripting client.

That’s probably HSTS getting in the way.

Why? Is your scripting client using OpenSSL 0.9.8y, or running on Android 2.3.7?


It’s using open source encryption software dated 2007. So, it may well be a bit out of date :frowning:

The SSL Labs report indicates that TLS v1.0 is enabled. That standard was published in 1999. If your scripting client doesn’t support at least TLS v1.0, you really need to upgrade it, and if it does, then you’re OK. It’s possible that none of the available cipher suites are ones your scripting client supports, but in that case, again, you probably want to upgrade your scripting client, because everything else is pretty nasty.

Once again, though, I’m only guessing, because you’re providing very vague answers, rather than anything concrete.


Well, it’s an open source product so if it can be fixed, then we will try.

So, here’s our discussion of the issue here

Are there other discourse sites using Letsencrypt that I can check against to see if it’s a configuration issue on our side that is breaking us.

This site and letsencrypt itself can be read by our scripting agent.

Try this one:

1 Like

That one reads fine!

The thought is that

“our discourse server” only supports TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA or TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, while rebol only supports these

So, if I can change the cipher suite to one rebol supports, then we’ll also be suite.

1 Like

I ran the ssllabs report on and it supports for TLS 1.0

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   ECDH secp256r1 (eq. 3072 bits RSA)   FS	128
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33)   DH 2048 bits   FS	128
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   ECDH secp256r1 (eq. 3072 bits RSA)   FS	256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39)   DH 2048 bits   FS

So, I guess I need to find out how I can configure the support for TLS_DHE_RSA_WITH_AES_128_CBC_SHA which we have

The cipher suite settings appear to be here


So, I have tried to put in TLS-DHE-RSA-WITH-AES-256-CBC-SHA but I’ve run out of disk space so can’t commit the changes. :frowning:

I resized the disk and rebuilt but it hasn’t changed the cipher suites available.

The chaps at tell me they use a discourse hosted instance so don’t know what their SSL template web.ssl.template.yml says.

Would anyone here know?

Run ./launcher cleanup and sudo apt clean

1 Like

Thanks. I’ll give that a go but in the meantime I’ve increased the disk size

Nice, that doubled the amount of free space I had.

  1. mkdir -p containers/templates (this is not in source control)

  2. cp templates/web.ssl.template.yml containers/templates

  3. fuss with the file

  4. add containers/templates/web.ssl.template.yml to you app.yml file in the templates section

  5. profit

1 Like