Sorry, I'm not really sure what's going on here. Just to test, have you tried loading the cert temporarily without using autocert?
You probably need to setup a system to reproduce this and get more info. I know there have been some issues in the past with WinXP and LetsEncrypt certs, though I don't know if it's related as those caused invalid certificate errors. On Tue, Feb 7, 2017 at 7:01 AM, Alexandr Emelin <frv...@gmail.com> wrote: > Copied wrong line from Heroku proxy report, here is the correct one: > > Chrome 49 / XP SP3 > <https://www.ssllabs.com/ssltest/viewClient.html?name=Chrome&version=49&platform=XP%20SP3&key=136> > RSA > 2048 (SHA256) > <https://www.ssllabs.com/ssltest/analyze.html?d=centrifugo.herokuapp.com#3605008a4b977a443f4f14e3c072d362c55475e7797b46554cc3088f8cbfa11b> > TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS > > вторник, 7 февраля 2017 г., 14:59:42 UTC+3 пользователь Alexandr Emelin > написал: > >> James, thanks for response. I am using go1.7.5 linux/amd64 >> >> I have no that client available too - it was originally seen in >> production logs, and now I rely only on SSLLabs handshake emulation feature >> that has that Chrome 49 SP3 client in list. >> >> Here is what SSLLabs shows for that client when application behind Heroku >> proxy: >> >> Firefox 49 / XP SP3 >> <https://www.ssllabs.com/ssltest/viewClient.html?name=Firefox&version=49&platform=XP%20SP3&key=137> >> RSA >> 2048 (SHA256) >> <https://www.ssllabs.com/ssltest/analyze.html?d=centrifugo.herokuapp.com#3605008a4b977a443f4f14e3c072d362c55475e7797b46554cc3088f8cbfa11b> >> TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS >> >> For Go I used both examples from https://gist.github.com/FZambi >> a/b51fa33ea4ec78caa7722299da5ae09e - one with default config, and one >> with all available cipher suites set in TLSConfig and >> PreferServerCipherSuites option. Both examples use autocert (Let's Encrypt) >> to get HTTPS certificate. Output of SSLLabs in both cases is: >> >> Chrome 49 / XP SP3 >> <https://www.ssllabs.com/ssltest/viewClient.html?name=Chrome&version=49&platform=XP%20SP3&key=136> >> Server >> sent fatal alert: handshake_failure >> >> And no cipher suite supported by both client and server in logs for this >> handshake. >> >> понедельник, 6 февраля 2017 г., 17:15:04 UTC+3 пользователь James Bardin >> написал: >>> >>> >>> What cipher quite is negotiated when you connect to the Heroku proxy? >>> >>> What version of Go are you using on the server, and are you using the >>> default tls.Config? >>> >>> I don't have that client directly available to test with, but does your >>> particular client show the expected information when you visit >>> https://www.ssllabs.com/ssltest/viewMyClient.html? >>> >>> >>> On Sunday, February 5, 2017 at 3:44:47 AM UTC-5, Alexandr Emelin wrote: >>>> >>>> When using builtin TLS for http/websocket server I noticed that >>>> handshakes from some old browser clients fail. The reason why I find this >>>> strange is that other TLS implementations work with those connections >>>> without any problems. I used ssllabs.com/ssltest/ >>>> <https://www.ssllabs.com/ssltest/> to emulate handshakes. >>>> >>>> To be more specific: clients using Chrome 49 on Windows XP SP3 can't >>>> establish secure connection with my Go server. When I use Heroku reverse >>>> proxy in front of the app - connection succesfully established using TLS >>>> 1.2. In case of Go I see "*tls: no cipher suite supported by both >>>> client and server*" message in server log. >>>> >>>> I investigated this a bit and found that actually client and server >>>> have many cipher suites in common but none of them set in >>>> setCipherSuite >>>> <https://github.com/golang/go/blob/81038d2e2b588f9df45d20a2ca0be446b0e421b2/src/crypto/tls/handshake_server.go#L770> >>>> function. Here is list of supported and preference suites: >>>> >>>> Supported: []uint16{0xc02f, 0xcca8, 0xcc13, 0xc014, 0xc013, 0x9c, 0x35, >>>> 0x2f, 0xa} >>>> Preference: []uint16{0x5600, 0xc02f, 0xc02b, 0xc030, 0xc02c, 0xc011, >>>> 0xc007, 0xc013, 0xc009, 0xc014, 0xc00a, 0x9c, 0x9d, 0x5, 0x2f, 0x35, >>>> 0xc012, 0xa} >>>> >>>> >>>> They are all rejected by this code >>>> <https://github.com/golang/go/blob/81038d2e2b588f9df45d20a2ca0be446b0e421b2/src/crypto/tls/handshake_server.go#L784> >>>> (some >>>> because there were no rsaSignOk set, some because there was no >>>> rsaDecryptOk set). >>>> >>>> trying 0xc02f for version 0x303 >>>> reason rejected: !rsaSignOk >>>> >>>> trying 0xc013 for version 0x303 >>>> reason rejected: !rsaSignOk >>>> >>>> trying 0xc014 for version 0x303 >>>> reason rejected: !rsaSignOk >>>> >>>> trying 0x9c for version 0x303 >>>> reason rejected: !rsaDecryptOk >>>> >>>> trying 0x2f for version 0x303 >>>> reason rejected: !rsaDecryptOk >>>> >>>> trying 0x35 for version 0x303 >>>> reason rejected: !rsaDecryptOk >>>> >>>> trying 0xa for version 0x303 >>>> reason rejected: !rsaDecryptOk >>>> >>>> >>>> I am not skilled in TLS area so looking for help – what's going on >>>> here, why Go implementation does not support connections supported by other >>>> TLS termination proxies? >>>> >>>> -- > You received this message because you are subscribed to a topic in the > Google Groups "golang-nuts" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/golang-nuts/neu_jKq9pYk/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
