I have a collection of SLES11 Sp4 boxes here being managed and patched via SUSE Manager. All of them are more-or-less current (SLES Sp4 updates applied up through last week, SUSE Manager is on SLES12 Sp2 with updates applied last week). Most of them work fine when being scheduled to patch (managed via Salt, if that matters). A few fail to patch.
I can see that Zypper attempts to fetch its patches from SuMa using curl. I can reproduce the symptom using curl or wget, so it’s not a Zypper problem. Basically, what I see (packet trace) is that the curl client goes out and makes a https:// attempt with TLSv1, which is kicked back. Through some investigation, we seem to have found a device that is on the network between the SLES11 server and the SuMa server. I think what I’m seeing is that this device is acting as a proxy, intercepting the https:// traffic, trying to “step up” the connection to TLSv1.2, which is then rejected, and it kills the connection.
Interestingly, if I immediately retry, the https:// connection goes through to SuMa and away we go. There’s about a 5 minute window during which this mysterious device allows TLSv1 connections, then it goes back to trying to step up to TLSv1.2.
Given that SuMa is up to date, it seems that it should accept TLSv1.2 connections. What I’m looking for / hoping to find, is a way to get curl to use TLSv1.2 by default. But since it’s being called from Zypper, I have no control over how curl is being used to fetch patches. Whether that will convince this device to get out of the way of the connections, I don’t know, but it seems worth a try.