On 17.11.2018 18:32, Andrea Pescetti wrote: > Dave Fisher wrote: >> I’ve been on with Infra on HipChat and both servers are the same with >> the same content internally, > > Yes, I don't see this as a major issue either. It is probably too > early for Infra to jump in, since we haven't identified major > network-related issues so far (yes, one of the two server does not > respond to ping and traceroute, but I can get updates from it > nevertheless). I mean, of course it doesn't harm but we need to shed > more light, see below. > >> I’m being asked for IP addresses to share so that can see if there is >> an IP ban happening. > > A ban is for sure not the case. > > Indeed, I have interesting news: I can reproduce the bug on an Ubuntu > system. My best bet at the moment is that something in the SSL > negotiation is wrong. > > A nice additional benefit is that this gives us a simple way to > reproduce the bug, equivalent to the update notification. > > $ soffice https://ooo-updates.apache.org/index.html > > (this fails on Ubuntu, succeeds on Fedora) > > Note that > > $ soffice https://www.google.com/ > > will work in all cases (so this is not an HTTPS bug per se) and > > $ soffice http://ooo-updates.apache.org/index.html > > will work in all cases (so this not a network issue but rather an SSL > issue). > > Now, debugging SSL issues is not easy, but can the people who don't > get updates at least confirm the three results above, i.e., that only > the first one fails? > > Further tests show that problematic systems have issues with ASF sites > in HTTPS, like: > $ soffice https://www.apache.org/ # Fails > $ soffice http://www.apache.org/ # Succeeds > $ soffice https://www.openoffice.org/ # Fails > $ soffice http://www.openoffice.org/ # Succeeds > $ soffice https://... # Succeeds for any site I put there, except ASF > sites, but I'd love to see a non-ASF example of a failing HTTPS site. > > If this is confirmed we are really close to a point where we could > actually get useful information from Infra.
Note that all the sites that fail in your list have wildcard certificates — CN=*.apache.org for the Apache sites and CN=*.openoffice.org for the OO sites. This may be related to wildcard cert support in OpenSSL/LibreSSL/GnuTLS/whateveryou'reusing on the affected systems. Correlating this with the SSL library name and version would be useful. (I'm on macOS, so using Apple's crypto library which does support wildcard certs). For debugging, I suggest using cURL instead of OO, for example: curl -sviI https://www.openoffice.org/ -- Brane --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
