A quick update on this. As of now, 24 Aug 11:30am UTC, it's failing again, but only from our office broadband connection, it's working from our London VPS. The resolved IP addresses seem to have shifted around a bit in some locations - currently dashboard.geospock.com is resolving to 64.233.166.121 from our office connection.
Would really appreciate some information on what's going on here. Jon On Saturday, 22 August 2015 10:04:01 UTC+1, Jon Travers wrote: > > Hi Patrice, thanks for your reply. I'm Kai's colleague here in the UK, and > have been working with him on this problem. To answer your question: > > The manifestation of the problem when we pointed a browser at our web app ( > https://dashboard.geospock.com), and forced a full refresh, was that the > browser would refuse to connect at all, showing an error something like > "Safari was unable to establish a secure connection to the website". As Kai > mentioned, whether or not it worked was dependent on which network we > connected from: It failed on our UK office broadband connection, and from a > VPS located in London, whereas it worked fine on our UK mobile data > connections, from a San Fransisco VPS, and also on my UK broadband > connection at home (different ISP). The easiest way I found to test was to > run the following openssl command: > > openssl s_client -servername dashboard.geospock.com -connect > dashboard.geospock.com:443 -showcerts > > If successful, this prints out our custom SSL certificate (the app is > hosted via a custom Google Apps domain). When it failed, openssl would > crash, with the following output: > > CONNECTED(00000003) > > 58671:error:14077417:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert > illegal > parameter:/SourceCache/OpenSSL098/OpenSSL098-52.30.1/src/ssl/s23_clnt.c:593: > > Where possible, we made a note of the IP addresses resolved for > dashboard.geospock.com in the locations we were testing. For our > (failing) office network, we were always routed to: 64.233.167.121, from > the London VPS (not working) we got 64.233.166.121, whereas from the SFO > VPS (which worked), we got 173.194.79.121, and from my home broadband > (also working) I get 173.194.67.121. > > I notice that currently when I run the openssl test, but connect it > directly to one of the failing resolved IP addresses, or try the London VPS > (which was failing), it's working fine. I suppose this means the problem > has now been resolved. It certainly was still failing yesterday when we > originally posted, and for at least 24 hours before that. > > The whole situation is very concerning for us, since all our production > apps are hosted on App Engine with custom SSL certificates served via > Google Apps domains. If our apps are failing intermittently for periods of > several days in some locations, that will have a very serious impact on our > business. We need to understand exactly what happened, and how we can > prevent it in the future. > > Thanks > Jon > > On Friday, 21 August 2015 19:56:53 UTC+1, Patrice (Cloud Platform Support) > wrote: >> >> Hi Kai, >> >> What exact error do you get when you connect from the UK? A screenshot >> with the exact error might be interesting to see so we can further >> troubleshoot this. >> >> Cheers! >> >> On Friday, August 21, 2015 at 7:14:50 AM UTC-4, Kai van Duuren wrote: >>> >>> We are having problems serving our web app on App Engine with SSL on a >>> custom domain. We had followed the instructions for uploading a certificate >>> to a custom domain via the admin console. This had been working without >>> problems for several weeks, but since yesterday we have been observing some >>> SSL connection errors. >>> >>> Retrieving the main page from our location in the UK results in a >>> connection error. Accessing via a proxy in San Fransisco loads the page >>> without problem. >>> >>> We have tried deleting and reinstalling the certificate via the admin >>> console but this had no effect. >>> >>> The url in question is https://dashboard.geospock.com >>> >>> What could be causing this? Is this a routing issue internal to Google >>> or could it be a configuration problem on our end? >>> >>> Thanks. >>> >> -- 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 google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. 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/e2d34fe3-f3ad-45b6-98ef-665b2ead5154%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
