Bug ID 1127591
Summary zypper option "ssl_capath" not working for mirror URLs from metalink file
Classification openSUSE
Product openSUSE Distribution
Version Leap 15.0
Hardware x86-64
Status NEW
Severity Normal
Priority P5 - None
Component libzypp
Assignee zypp-maintainers@forge.provo.novell.com
Reporter cunix@bitmessage.ch
QA Contact qa-bugs@suse.de
CC security-team@suse.de
Found By ---
Blocker ---

Using zypper (version: 1.14.12)  for the update repository of openSUSE Leap
15.0 with the option


does not use the here configured trusted root certificates for mirror URLs,
probably retrieved from a metalink file.

The configured path is used for the initial connection to download.opensuse.org
but following requests to mirrors seem to fallback to the system trusted certs
from /etc/ssl/certs.

If the mirrors' root CA is trusted in
"ssl_capath=/path/to/directory/with/c_rehash/rootCAs" but not in
/etc/ssl/certs, zypper,libzypp, multi-curl or something else aborts the
TLS-Handshake with failure "Unknown CA (48)" and falls futher back to http
(without transport layer encryption).

Question for cc'ed security-team to answer:
If using clear text is considered a security flaw where zypper is configured to
use (https-)encryption, this might have security implications.

Some Scenarios:

Assume download.opensuse.org is signed by CA A
and the mirror by CA B

Assume further,
is directory C

and directory D is

If C includes A and B and in D at least B is not available, I would expect
zypper to encrypt both connection, but the request to the mirror is not.

If A is not in C, no data (meta link file) is retrieved and therefore no mirror
is connected - Good!
No fallback of looking for A in D occurs.

If A is in C and B in D, both connections are encrypted.

If A is in C and B not in C and not in D, the mirror is contacted unencrypted -
here I'm unsure if using plain text in this scenario is correct or if it should

So, in my opinion, 1. is the bug, 3. a workaround and 4. perhaps needs a zypper
option to configure, if clear text fallback should be allowed.

Another question is, if /etc/ssl/certs should actually be consulted when the
option "ssl_capath" is used and pointing to a different directory.

might be related (similar setup).
Problem and solution might be similar, too.

By the way, is there a debugging option to dump the traffic from inside the
encrypted connection?
Especially being able to read the metalink file with the listed mirrors is of

You are receiving this mail because: