Hi Patrice, thanks for your reply. Unfortunately, your explanation does not fit the facts which I've supplied. Let me try to convince you by restating in more detail two parts of my investigation:
1. Ignoring openssl for a moment, it is a FACT that if I open up the latest version of Chrome on my laptop here in our office, and type in the URL https://dashboard.geospock.com, the page doesn't load, and displays the following error: SSL connection error ERR_SSL_PROTOCOL_ERROR Unable to make a secure connection to the server. This may be a problem with the server, or it may be requiring a client authentication certificate that you don't have. It's doing this right now, as I type this. If I repeat the test on my home broadband connection, it loads and works just fine. The latest version of Chrome quite clearly supports all the latest TLS versions (right?), so you can't explain that away by claiming that I need to upgrade to a client the supports more than SSLv3. That's what I'm doing! 2. Looking at the openssl results, I also observed the debug info mentions SSLv3, and found that very odd. I experimented with using the openssl switches to disallow SSLv3 connections, and it had no effect on the behaviour. I also noted that in cases where it works (on the same computer, with the exact same command line), openssl indicates that it has established a TLSv1 connection, not SSLv3. So my conclusion is that the SSLv3 info in the crash is there because the SSL negotiation is somehow being corrupted, causing openssl to attempt to fallback to SSLv3, and then crashing it. For the record, the version of openssl on my computer is OpenSSL 0.9.8zg 14 July 2015. So the bottom line here, unless you're prepared to investigate further, is that serving App Engine apps on a custom Google Apps domain using a custom certificate via SNI is unusable (because it might fail randomly at any time in any geographical location). I suppose we could try using a virtual IP address instead, but that absolutely shouldn't be necessary. For our business-critical apps, we've now rerouted our traffic via our own SSL proxy to achieve exactly what Google Apps is supposed to be doing (our proxy is using SNI), and that's working just fine, while the Google infrastructure continues to fail. I find this unacceptable. Is there really nothing more you can do? On Wednesday, 26 August 2015 15:11:32 UTC+1, Patrice (Cloud Platform Support) wrote: > > Hi Jon, > > Sorry for the delay, there was a lot of movement and investigation to get > to the bottom of this. What seems to be the issue is that older clients > that support sslv3 but not tls appeared to get errors. > > Running $ openssl s_client -ssl3 -connect <fqdn>:443 -servername <fqdn> > would always fail with a handhshake error. As soon as we drop "-ssl3, > everything goes ok. Looking into the "illegal parameter" you get, we cannot > reproduce, and we have to pin it down to the version of software that > you're running. Looking online, every report of open ssl throwing "illegal > parameter" seemed to have to do with the version of openSSL or a > client-side config. > > I then went to check with the back-end team to see what was happening > there. Turns out it is indeed working as intended. SNI does not support > SSLv3. To get such a certificate up and running, I would suggest moving to > a Virtual IP <https://cloud.google.com/appengine/docs/ssl#virtual_ip_vip>, > which can help your situation. > > I hope that this will provide enough to shed some light on this. > > Cheers > > > > > On Monday, August 24, 2015 at 11:09:22 AM UTC-4, Jon Travers wrote: >> >> Yes certainly. For the two locations where we've seen problems: our >> office broadband is using IP address 94.10.92.68, and our London VPS is >> on 46.101.45.203. >> >> Hope that helps >> Jon >> >> On Monday, 24 August 2015 15:57:47 UTC+1, Patrice (Cloud Platform >> Support) wrote: >>> >>> Hi Jon, >>> >>> Thank you for all that extra information, this definitely will help in >>> finding out what issue you're having. >>> >>> Do you have on hand the IPs of the different locations/VPSes? I'm trying >>> to investigate, but having the exact IP that threw up the request would >>> definitely be helpful. >>> >>> Cheers >>> >> -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/google-appengine. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/afcc98e4-e56b-4876-841b-28846f5292aa%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
