On Fri, Nov 26, 2021 at 2:34 PM Patrick Shanahan <paka@opensuse.org> wrote:

* Roger Oberholtzer <roger.oberholtzer@gmail.com> [11-26-21 06:55]:

...

I have trouble refreshing the status of a couple repositories on my pretty much up-to-date Tumbleweed system. The problem is with packman, as well as M17N:/fonts/openSUSE_Tumbleweed and windows:/mingw:/win64/openSUSE_Tumbleweed/. So it is both for some openSUSE and some non-openSUSE repos. Some external repos work, and some openSUSE work.

The message is generally this:

Repository 'MinGW64' is invalid. [mingw64|https://download.opensuse.org/repositories/windows:/mingw:/win6 /openSUSE_Tumbleweed/] Valid metadata not found at specified URL

History:

- Download (curl) error for 'https://download.opensuse.org/repositories/windows:/mingw:/win64/openSUSE_Tu...':

Error code: Curl error 60

Error message: SSL certificate problem: unable to get local issuer certificate

- Can't provide /repodata/526857fc123d7384947e093f8293170c026ad9f736e350bedeb65fd292475760-primary.xml.gz

So I have some sort of a certificate problem. If I run zypper search ca-certificates, It says:

S | Name | Summary | Type --+----------------------------------+-------------------------------------------------------+-------- i | ca-certificates | Utilities for system wide CA certificate installation | package | ca-certificates-cacert | CAcert root certificates | package i | ca-certificates-mozilla | CA certificates for OpenSSL | package | ca-certificates-mozilla-prebuilt | Pre-built CA certificates for OpenSSL | package | ca-certificates-steamtricks | Provides /etc/ssl/certs/ca-certificates.crt | package

It does not help to delete and redefine the repository.

Do I need to install ca-certificates-cacer? I Googled this, and the only solution I saw was for SUSE, using the SUSEConnect --cleanup command. Which I do not have on Tumbleweed.

08:31 crash:~ > cnf suseconnect

The program 'suseconnect' can be found in the following package: * suseconnect-ng [ path: /usr/bin/suseconnect, repository: zypp /(Tumbleweed.OSS) ]

Try installing with: sudo zypper install suseconnect-ng

Thanks for the pointer. Unfortunately, running the suggested command had no effect on this. I'm not sure it really did anything as I am running Tumbleweed. -- Roger Oberholtzer

On Fri, Nov 26, 2021 at 3:15 PM Andrei Borzenkov <arvidjaar@gmail.com> wrote:

...

The message is generally this:

Repository 'MinGW64' is invalid. [mingw64|https://download.opensuse.org/repositories/windows:/mingw:/win6 /openSUSE_Tumbleweed/] Valid metadata not found at specified URL

I do not see anything related to "certificates" here. This directory is indeed no more present, probably the project was restructured (there is no subproject with name "win6"). You need to ask the maintainers of this project.

Sigh. Cut and paste error in my e-mail message. The final '4' is missing in my message. It is correct in my configuration. The repo is: https://download.opensuse.org/repositories/windows:/mingw:/win64

Use openssl_c to check certificates chains. I can open this file without problem. Maybe you are redirected to a mirror which has issues.

I will check. It has been this way for a while.

...

It does not help to delete and redefine the repository.

Why do you expect it to help? It does not change certificates installed on remote servers.

It could have been that something on my system about that repo became confused. Such things have been known to happen. -- Roger Oberholtzer

On Fri, Nov 26, 2021 at 7:43 PM Andrei Borzenkov <arvidjaar@gmail.com> wrote:

On 26.11.2021 17:55, Roger Oberholtzer wrote:

...

...

Use openssl_c to check certificates chains. I can open this file without problem. Maybe you are redirected to a mirror which has issues.

I will check. It has been this way for a while.

Sorry, I actually meant s_client (or openssl s_client), but it will not work for this purpose - it does not try to access any file, so does not trigger any redirection.

Try with something like

$ curl -s -L -I https://download.opensuse.org/repositories/windows:/mingw:/win64/openSUSE_Tu... | grep location:

location: https://mirrorcache.opensuse.org/repositories/windows:/mingw:/win64/openSUSE...

location: https://mirrorcache-eu.opensuse.org/repositories/windows:/mingw:/win64/openS...

location: https://ftp.gwdg.de/pub/opensuse/repositories/windows:/mingw:/win64/openSUSE...

Using https://, I get only this: HTTP/2 404 date: Mon, 29 Nov 2021 08:10:44 GMT server: Apache vary: accept-language,accept-charset accept-ranges: bytes content-type: text/html; charset=utf-8 content-language: en Using http:// I get this: HTTP/1.1 404 Not Found Date: Mon, 29 Nov 2021 08:11:16 GMT Server: Apache Vary: accept-language,accept-charset Accept-Ranges: bytes Content-Type: text/html; charset=utf-8 Content-Language: en So neither return 'location:'

$

to see where you are redirected.

...

...

...

It does not help to delete and redefine the repository.

Why do you expect it to help? It does not change certificates installed on remote servers.

It could have been that something on my system about that repo became confused. Such things have been known to happen.

SSL certificate is not part of repo metadata and curl error 60 means unknown CA in peer certificate.

You cannot also exclude SSL interception. So

openssl s_client -connect ftp.gwdg.de:443 -quiet -no_ign_eof < /dev/null

for each host in the chain above would certainly be interesting.

I get this: depth=2 C = US, ST = California, L = San Francisco, O = Cisco, CN = Cisco Umbrella Primary SubCA verify error:num=20:unable to get local issuer certificate verify return:1 depth=1 O = Cisco, CN = Cisco Umbrella Secondary SubCA lon-SG verify return:1 depth=0 C = US, ST = California, L = San Francisco, O = "Cisco Systems, Inc.", CN = ftp.gwdg.de verify return:1 DONE So I seem to be missing some certificate(s). The Cisco Umbrella thing is the local security. It uses a Cisco DNS that helps them control access to unauthorized sites. I can access the site via my browser, so simple access is not the issue. -- Roger Oberholtzer

On Mon, Nov 29, 2021 at 9:54 AM Andrei Borzenkov <arvidjaar@gmail.com> wrote:

On 29.11.2021 11:16, Roger Oberholtzer wrote:

...

On Fri, Nov 26, 2021 at 7:43 PM Andrei Borzenkov <arvidjaar@gmail.com> wrote:

...

On 26.11.2021 17:55, Roger Oberholtzer wrote:

...

...

Use openssl_c to check certificates chains. I can open this file without problem. Maybe you are redirected to a mirror which has issues.

I will check. It has been this way for a while.

Sorry, I actually meant s_client (or openssl s_client), but it will not work for this purpose - it does not try to access any file, so does not trigger any redirection.

Try with something like

$ curl -s -L -I https://download.opensuse.org/repositories/windows:/mingw:/win64/openSUSE_Tu... | grep location:

location: https://mirrorcache.opensuse.org/repositories/windows:/mingw:/win64/openSUSE...

location: https://mirrorcache-eu.opensuse.org/repositories/windows:/mingw:/win64/openS...

location: https://ftp.gwdg.de/pub/opensuse/repositories/windows:/mingw:/win64/openSUSE...

Using https://, I get only this:

HTTP/2 404

Oh my! This is Tumbleweed, repository was updated, paths changed. Surprise ...

I'm not sure what you mean by this. The repo URL (which is all I have defined on my system) for these repos have not changed. What path are you referring to? Are you implying that I have done something incorrect on my system? Or that this is a Tumbleweed issue? What is the implication of the missing location: string?

...

...

You cannot also exclude SSL interception. So

openssl s_client -connect ftp.gwdg.de:443 -quiet -no_ign_eof < /dev/null

for each host in the chain above would certainly be interesting.

I get this:

depth=2 C = US, ST = California, L = San Francisco, O = Cisco, CN = Cisco Umbrella Primary SubCA verify error:num=20:unable to get local issuer certificate verify return:1 depth=1 O = Cisco, CN = Cisco Umbrella Secondary SubCA lon-SG verify return:1 depth=0 C = US, ST = California, L = San Francisco, O = "Cisco Systems, Inc.", CN = ftp.gwdg.de verify return:1 DONE

So I seem to be missing some certificate(s). The Cisco Umbrella thing is the local security. It uses a Cisco DNS that helps them control access to unauthorized sites. I can access the site via my browser, so simple access is not the issue.

Well, if you do not care if third party is able to decrypt your HTTPS traffic, why do you bother with HTTPS in the first place? Just use HTTP.

I only tried http:// and https:// to see if either of them gave a location:. Neither did.

Here is the actual certificate chain for this site

depth=3 C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust Center, CN = T-TeleSec GlobalRoot Class 2

verify return:1

depth=2 C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. V., OU = DFN-PKI, CN = DFN-Verein Certification Authority 2

verify return:1

depth=1 C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. V., OU = DFN-PKI, CN = DFN-Verein Global Issuing CA

verify return:1

depth=0 C = DE, ST = NIEDERSACHSEN, L = GOETTINGEN, O = Gesellschaft fuer wissenschaftliche Datenverarbeitung, CN = ftp6.gwdg.de

verify return:1

So, the question remains: is the certificate issue on my system? It probably is. If so, what can I do to remedy the situation? -- Roger Oberholtzer

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2021-11-29 at 10:42 +0100, Roger Oberholtzer wrote:

On Mon, Nov 29, 2021 at 9:54 AM Andrei Borzenkov <arvidjaar@gmail.com> wrote:

...

On 29.11.2021 11:16, Roger Oberholtzer wrote:

...

On Fri, Nov 26, 2021 at 7:43 PM Andrei Borzenkov <arvidjaar@gmail.com> wrote:

...

On 26.11.2021 17:55, Roger Oberholtzer wrote:

...

...

Use openssl_c to check certificates chains. I can open this file without problem. Maybe you are redirected to a mirror which has issues.

I will check. It has been this way for a while.

Sorry, I actually meant s_client (or openssl s_client), but it will not work for this purpose - it does not try to access any file, so does not trigger any redirection.

Try with something like

$ curl -s -L -I https://download.opensuse.org/repositories/windows:/mingw:/win64/openSUSE_Tu... | grep location:

location: https://mirrorcache.opensuse.org/repositories/windows:/mingw:/win64/openSUSE...

location: https://mirrorcache-eu.opensuse.org/repositories/windows:/mingw:/win64/openS...

location: https://ftp.gwdg.de/pub/opensuse/repositories/windows:/mingw:/win64/openSUSE...

Using https://, I get only this:

HTTP/2 404

Oh my! This is Tumbleweed, repository was updated, paths changed. Surprise ...

I'm not sure what you mean by this. The repo URL (which is all I have defined on my system) for these repos have not changed. What path are you referring to? Are you implying that I have done something incorrect on my system? Or that this is a Tumbleweed issue?

You were asked to run this command: curl -s -L -I https://download.opensuse.org/repositories/windows:/mingw:/win64/openSUSE_Tu... | grep location: You have delayed, so being tumbleweed, that file is gone. So open a browser and find the file that actually exists this minute when you receive this email. This minute it is "https://download.opensuse.org/repositories/windows:/mingw:/win64/openSUSE_Tu...", so I run: cer@Telcontar:~/tmp/Roger> curl -s -L -I https://download.opensuse.org/repositories/windows:/mingw:/win64/openSUSE_Tu... | grep location: location: https://mirrorcache.opensuse.org/repositories/windows:/mingw:/win64/openSUSE... location: https://mirrorcache-eu.opensuse.org/repositories/windows:/mingw:/win64/openS... location: https://ftp.byfly.by/pub/opensuse/repositories/windows:/mingw:/win64/openSUS... cer@Telcontar:~/tmp/Roger> Plain simple test. Don't try my command, it will be gone. Try the URL that is correct when you read this post.

What is the implication of the missing location: string?

See above. - -- Cheers, Carlos E. R. (from openSUSE 15.2 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCYaStAxwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVsiIAn0j/Mfh97uO084rUqdu5 UULRD9hxAJ412/55IaRf36YBGvrBI7V65DNw1Q== =2EkW -----END PGP SIGNATURE-----

On Mon, Nov 29, 2021 at 5:47 PM Roger Oberholtzer <roger.oberholtzer@gmail.com> wrote:

I have run the command now and I get this:

location: https://mirrorcache.opensuse.org/repositories/windows:/mingw:/win64/openSUSE... location: https://mirrorcache-eu.opensuse.org/repositories/windows:/mingw:/win64/openS... location: https://ftp.lysator.liu.se/pub/opensuse/repositories/windows:/mingw:/win64/o...

So, does it try the last location?

It probably does not matter because you have a man-in-the-middle box which replaces the remote server certificate with its own that is generated on the fly. I suspect curl errors out on the very first link already. Anyway, I suggested you check with s_client every host in this chain ... So yes, you are missing the root CA certificate of your intermediate box that would allow it silently intercept all HTTPS traffic. If you agree with it, you need to install this root CA. But you have already been told multiple times to simply use http instead of https - at least for this particular task.

Roger Oberholtzer wrote:

I have run the command now and I get this:

location:

https://mirrorcache.opensuse.org/repositories/windows:/mingw:/win64/openSUSE...

location:

https://mirrorcache-eu.opensuse.org/repositories/windows:/mingw:/win64/openS...

location:

https://ftp.lysator.liu.se/pub/opensuse/repositories/windows:/mingw:/win64/o...

So, does it try the last location?

Yes, the last one is tried, the others are 301 redirects. -- Per Jessen, Zürich (0.6°C)