Download (curl) error for ‘https://download.opensuse.org/repositories/system:/snappy/openSUSE_Leap_15.1/repodata/repomd.xml’:
Error code: Curl error 51
Error message: SSL: no alternative certificate subject name matches target host name ‘download.opensuse.org’
And is there a fix for it?
See https://status.opensuse.org/
As a workaround, the DNS was changed, but I guess only http will work (you’re using repositories over https)
Thanks that helped, I had to disable it for updates to be recognized.
One would think that if a repo address is ‘bad’, the update system would skip it and go on with the repo’s that are not ‘bad’. Instead of stopping everything.
Software Management is giving the same curl related error message BILL_L described for every repo in my configuration. I can click to skip checking on each repo and after the list has been gone through, Software Manager proceeds in a normal fashion regarding downloads and installs.
I checked the last set of updates (approximately 20 I picked up earlier today) and there was no curl update.
Something has broken curl’s involvement in acquiring updates from the repos.I have no knowledge of these processes.
I think there is a data server problem somewhere.
Tom Kosvic
Looks to me I am having the same issue on Tumbleweed. 
Gonna try the command-line.
Same error, just gonna wait for now.
The openSUSE download server is currently not fully functional: <https://status.opensuse.org/incidents/230>.
Our mirror server in Provo is now a complete replacement for download.opensuse.org (including database and redirector). Sadly some files are not up-to date on the machine, so you might not get the latest files that are built in our openSUSE build service for some time.
Meanwhile, we are working on the original download server to get it back as soon as possible.
It looks as if everything is now back to normal. An ip lookup now returns the European address instead of the temporary USA address.
Yes, according to the News feed – posted 3 hours ago: <https://status.opensuse.org/incidents/230>
https://download.opensuse.org/ is back to normal. Thanks to everyone involved in analyzing and fixing the root cause!
You may readily verify their claim:
erlangen:~ # time zypper ref --force
Forcing raw metadata refresh
Retrieving repository 'Application_Geo' metadata ......
All repositories have been refreshed.
real 0m7.690s
user 0m3.984s
sys 0m0.473s
erlangen:~ #
Maybe I have more: >:)
# time zypper refresh --force
Aktualisieren der Rohmetadaten erzwingen
Metadaten von Repository 'openSUSE BuildService - PHP:Applications' abrufen ....................................[fertig]
Erstellen des Repository-Cache erzwingen
Cache für Repository 'openSUSE BuildService - PHP:Applications' erzeugen .......................................[fertig]
.
.
.
real 0m44,240s
user 0m13,350s
sys 0m0,904s
#
I have:
erlangen:~ # du -hd1 /var/cache/zypp/raw
396K /var/cache/zypp/raw/Application_Geo
92K /var/cache/zypp/raw/BellSoft
1.5M /var/cache/zypp/raw/Packman
16K /var/cache/zypp/raw/chrome
392K /var/cache/zypp/raw/home_X0F_HSF
20K /var/cache/zypp/raw/jalbum
16K /var/cache/zypp/raw/myrepo
27M /var/cache/zypp/raw/openSUSE-20191106-0
20K /var/cache/zypp/raw/opensuse-guide.org
88K /var/cache/zypp/raw/repo-non-oss
32K /var/cache/zypp/raw/repo-update
30M /var/cache/zypp/raw
erlangen:~ #
Connection is FTTB/VDSL2, 25 Mbit/s down, 5 Mbit/s up.
Strange, we have VDSL2 17a (ITU G.993.2) 51,39 Mbit/s down and 10,04 Mbit/s up – got taken down for maintenance about one hour ago …
# du -hd1 /var/cache/zypp/raw/
4,2M /var/cache/zypp/raw/repo-source
28K /var/cache/zypp/raw/adobe
152K /var/cache/zypp/raw/Build_Service:_PHP:_Applications
24K /var/cache/zypp/raw/opensuse-guide.org-repo
2,6M /var/cache/zypp/raw/repo-debug-update
80K /var/cache/zypp/raw/repo-non-oss
5,4M /var/cache/zypp/raw/repo-debug
64K /var/cache/zypp/raw/repo-source-non-oss
48K /var/cache/zypp/raw/repo-update-non-oss
24K /var/cache/zypp/raw/repo-debug-update-non-oss
48K /var/cache/zypp/raw/repo-debug-non-oss
184K /var/cache/zypp/raw/hardware
564K /var/cache/zypp/raw/packman.inode.at-suse
21M /var/cache/zypp/raw/repo-oss
4,5M /var/cache/zypp/raw/openSUSE-Leap-15.1-1
268K /var/cache/zypp/raw/KDE:_Extra
25M /var/cache/zypp/raw/repo-update
64M /var/cache/zypp/raw/
#
Your’s are maximum values, not typical ones. Mine are nominal values. M-net guarantees 90% of nominal. Actual ones are 27,5 Mbit/s and 5,5 Mbit/s. Connection is up since 24. March 2020:
erlangen:~ # ping -c 3 opensuse.org
PING opensuse.org(proxy-nue.opensuse.org (2001:67c:2178:8::16)) 56 data bytes
64 bytes from proxy-nue.opensuse.org (2001:67c:2178:8::16): icmp_seq=1 ttl=59 time=15.5 ms
64 bytes from proxy-nue.opensuse.org (2001:67c:2178:8::16): icmp_seq=2 ttl=59 time=16.2 ms
64 bytes from proxy-nue.opensuse.org (2001:67c:2178:8::16): icmp_seq=3 ttl=59 time=15.4 ms
--- opensuse.org ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 15.437/15.687/16.159/0.333 ms
erlangen:~ #
Broadband measurement via the German Federal Network Agency reveals that, my Downlink is running at 94,1 % of the maximum possible rate and, the Uplink is running at 92,5 % of the maximum possible rate – both of which are bit-rates more than the Agency’s nominal target bit-rate – my ISP won’t receive a visit by the Agency’s staff triggered by unacceptable throughput figures … 
I got 101.5%, 101%, 18ms (Frankfurt). Zypper dup gets 109% which is what the Fritz!Box displays.
Yes, your mileage may vary – depending on the time of day – which is why the Federal Agency recommends testing on two separate days with 10 measurements per day.