"tls: no cipher suite supported by both client and server" - alexa custom skill API can not make secure connection to caddy server

1. Caddy version (caddy version):

caddy_darwin_arm64
v2.3.0 h1:fnrqJLa3G5vfxcxmOH/+kJOcunPLhSBnjgIvjXV/QTA=

2. How I run Caddy:

caddy run

a. System environment:

Mac mini (M1, 2020)
11.0.1 (20B29)

b. Command:

caddy run

d. My complete Caddyfile or JSON config:

{
  email XXX@XXX
  debug
}


services.XXX.com {
  tls {
      #protocols tls1.2 tls1.2
      issuer zerossl
}

 reverse_proxy /shows* 192.168.214.30:8989
 reverse_proxy /movies* 192.168.214.30:7878
 reverse_proxy /sabnzbd* 192.168.214.30:8080
 reverse_proxy /alexa* 192.168.214.20:1415


 basicauth /shows* {
  XXX XXX
 }
 basicauth /movies* {
  XXX XXX
 }
 basicauth /sabnzbd* {
  XXX XXX
 }

}

3. The problem I’m having:

alexa API service can not connect to caddyserver with TLS issues

thown error is from http.stdlib when hs.suite== nil

4. Error messages and/or full log output:

meedia@meedia-2 caddy % caddy run    
2021/03/13 05:08:35.704	INFO	using adjacent Caddyfile
2021/03/13 05:08:35.706	INFO	admin	admin endpoint started	{"address": "tcp/localhost:2019", "enforce_origin": false, "origins": ["localhost:2019", "[::1]:2019", "127.0.0.1:2019"]}
2021/03/13 05:08:35.707	INFO	tls.cache.maintenance	started background certificate maintenance	{"cache": "0x140003d19d0"}
2021/03/13 05:08:35.707	INFO	http	server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS	{"server_name": "srv0", "https_port": 443}
2021/03/13 05:08:35.707	INFO	http	enabling automatic HTTP->HTTPS redirects	{"server_name": "srv0"}
2021/03/13 05:08:39.013	DEBUG	http	starting server loop	{"address": "[::]:443", "http3": false, "tls": true}
2021/03/13 05:08:39.013	DEBUG	http	starting server loop	{"address": "[::]:80", "http3": false, "tls": false}
2021/03/13 05:08:39.013	INFO	http	enabling automatic TLS certificate management	{"domains": ["services.28seven.com"]}
2021/03/13 05:08:39.015	INFO	tls	cleaned up storage units
2021/03/13 05:08:39.020	INFO	autosaved config	{"file": "/Users/meedia/Library/Application Support/Caddy/autosave.json"}
2021/03/13 05:08:39.020	INFO	serving initial configuration
2021/03/13 05:08:42.022	DEBUG	http.stdlib	http: TLS handshake error from 72.21.217.41:11286: tls: no cipher suite supported by both client and server
^C2021/03/13 05:08:45.779	INFO	shutting down	{"signal": "SIGINT"}
2021/03/13 05:08:45.782	INFO	tls.cache.maintenance	stopped background certificate maintenance	{"cache": "0x140003d19d0"}
2021/03/13 05:08:45.783	INFO	admin	stopped previous server
2021/03/13 05:08:45.783	INFO	shutdown done	{"signal": "SIGINT"}

5. What I already tried:

  • Validated that endpoint is properly exposed and functioning from the browser
  • Tried forcing TLS 1.2
  • Tried changing cert issuer
  • Tried changing cert options from Alexa, Screen Shot 2021-03-13 at 1...
  • validated TLS on Alexa API endpoint https://api.amazonalexa.com/
  • validated that Alexa is recognizing a SSL problem and it’s not a connection issue Cannot establish SSL connection to your skill endpoint.

6. Links to relevant resources:

Still working to try to get this figured out. I am convinced that this is an Alexa api service quark but I’m very surprised that Caddy can’t provide any more useful log information to help me debug. Checking the forms it seems like someone else experienced this same issue with apple pay.

any help is appreciated

like issue in help

Did a quick search and these appear to be the default ciphers Caddy uses:

The full list of supported ciphers at the time of this post is:

TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256

tls (Caddyfile directive) — Caddy Documentation

If you can find out which ciphers Alexa’s client supports you can use the tls directive to enable it as long as it’s in that supported list, I think.

As it stands I’m not sure Caddy can give you any more detailed information, since it’s just a matter of Alexa’s client sending one cipher list, Caddy comparing it to its own cipher list, and not finding any matches.

Looking at the alexa API service it appears that there is overlap between what caddy offers and their configuration. TLS_AES_128_GCM_SHA256 should be a shared TLS 1.3 suite

Shared with CloudApp

Next update:

Looking at comms with wireshark Alexa is always sending with TLS 1.2 so i updated my config to accept both. Looking at the sent cipher suites, there is definitely a overlap between what Caddy supports and what is being sent

Request from Alexa:
Shared with CloudApp

handshake failure:
Shared with CloudApp

Can we see your current config?

  email XXX@XXX.com
  debug
}


services.XXX.com:443 {
 tls {
  protocols tls1.2 tls1.3
  #issuer zerossl
 }

 reverse_proxy /shows* 192.168.214.30:8989
 reverse_proxy /movies* 192.168.214.30:7878
 reverse_proxy /sabnzbd* 192.168.214.30:8080
 reverse_proxy /alexa* 192.168.214.20:1415


 basicauth /shows* {
  XXX XXX
 }
 basicauth /movies* {
  XXX XXX
 }
 basicauth /sabnzbd* {
  XXX XXX
 }

}

TLS_AES_128_GCM_SHA256 might be an overlapping cipher but it’s supported, not enabled by default in Caddy as far as I can tell (see: "tls: no cipher suite supported by both client and server" - alexa custom skill API can not make secure connection to caddy server - #3 by Whitestrake)

Try enabling it with the ciphers subdirective for the tls directive:

same results

{
  email XXX@XXX.com
  debug
}


services.XXX.com:443 {
 tls {
  protocols tls1.2 tls1.3
  #issuer zerossl
  ciphers TLS_AES_128_GCM_SHA256
 }

 reverse_proxy /shows* 192.168.214.30:8989
 reverse_proxy /movies* 192.168.214.30:7878
 reverse_proxy /sabnzbd* 192.168.214.30:8080
 reverse_proxy /alexa* 192.168.214.20:1415


 basicauth /shows* {
  XXX XXX
 }
 basicauth /movies* {
  XXX XXX
 }
 basicauth /sabnzbd* {
  XXX XXX
 }

}```

Are you absolutely sure Alexa’s client is actually preferencing that cipher?

A quick Google shows some evidence that Alexa’s client cipher preferences can be pretty wildly out of date.

You could also run that TLS check again on your Caddy server to confirm it does, indeed, now support the cipher you’ve configured it for in tls1.2.

Good call.

my caddy server is not running with TLS1.2
Shared with CloudApp

so i changed my config to only allow 1.2 (with protocols tls1.2 tls1.2)

and now i have no SSL capabilities
Shared with CloudApp

I installed caddy from homebrew. I did the same install process on a m1 macmini and intel macbook pro, both are showing the same issue. could my install be bad?

just did a brew reinstall caddy and tested with the same results

:grimacing: nope got ahead of myself. tls 1.2 wasn’t working because of a cipher mismatch. once i commented out the TLS_AES_128_GCM_SHA256 which is a TLS 1.3 cipher everything came back to life

tls {
  protocols tls1.2 tls1.2
  #issuer zerossl
  #ciphers TLS_RSA_WITH_3DES_EDE_CBC_SHA
 }

Shared with CloudApp

:tada: got it!!!

final config

{
  email XXX@XXX.com
  debug
}


services.XXX.com:443 {
 tls {
  #issuer zerossl
  ciphers TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_AES_128_GCM_SHA256 TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
 }

 reverse_proxy /shows* 192.168.214.30:8989
 reverse_proxy /movies* 192.168.214.30:7878
 reverse_proxy /sabnzbd* 192.168.214.30:8080
 reverse_proxy /alexa* 192.168.214.20:1415


 basicauth /shows* {
  XXX XXX
 }
 basicauth /movies* {
  XXX XXX
 }
 basicauth /sabnzbd* {
  XXX XXX
 }

}

so it def came down to me not understanding that not all supported ciphers were enabled by default.

If anyone ever gets stuck with this again, Wireshark was very helpful to understand what should be supported by the connecting server. Alexa does use some older algorithms and are classified as weak so i get why its not enabled by default

right now I have a whole bunch of specified ciphers but I will likely review all my connections then pair that list down to get rid of some of the less secure algorithms.

Suggested documentation updates

  • make clearer in the documentation that not all ciphers are enabled by default
  • docs say Note that cipher suites are not customizable with TLS 1.3. I read that as “the ciphers directive will not work if you have tls 1.3 enabled”. it would be helpful to explicitly say that you can customize the list of enabled tls1.2 ciphers even if you are using 1.3
2 Likes

Nice, thanks for the feedback.

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