Thank you for your participation. 
Yes, it’s pretty much the same here. The https URL to the repo has a valid Let’s Encrypt certificate.
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R10
verify return:1
depth=0 CN = xxx
verify return:1
---
Certificate chain
0 s:CN = xxx
i:C = US, O = Let's Encrypt, CN = R10
a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
v:NotBefore: Jun 13 01:17:38 2024 GMT; NotAfter: Sep 11 01:17:37 2024 GMT
1 s:C = US, O = Let's Encrypt, CN = R10
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
v:NotBefore: Mar 13 00:00:00 2024 GMT; NotAfter: Mar 12 23:59:59 2027 GMT
---
...
Nothing special and it is working fine.
Completely independent of this Let’s Encrypt certificate, is the client side certificate, which uses zypper to authenticate against the server (rather than username/passwords). This certificate was generated by my own internal CA.
The web server and the client knows about the own certificate chain - and it is working as long I use firefox or curl directly like:
curl -v --cert /var/lib/zypp/example-client-d.crt --key /var/lib/zypp/example-client-d.key https://repo.example.org/example-main/
* Host repo.example.org:443 was resolved.
* IPv6: (none)
* IPv4: xxx
* Trying xxx:443...
* Connected to repo.example.org (xxx) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519 / RSASSA-PSS
* ALPN: server accepted http/1.1
* Server certificate:
* subject: CN=repo.example.org
* start date: Jun 13 01:17:38 2024 GMT
* expire date: Sep 11 01:17:37 2024 GMT
* subjectAltName: host "repo.example.org" matched cert's "repo.example.org"
* issuer: C=US; O=Let's Encrypt; CN=R10
* SSL certificate verify ok.
* Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
* Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
* Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
* using HTTP/1.x
> GET /example-main/ HTTP/1.1
> Host: repo.example.org
> User-Agent: curl/8.8.0
> Accept: */*
>
* Request completely sent off
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* TLSv1.3 (IN), TLS handshake, Request CERT (13):
* TLSv1.3 (OUT), TLS handshake, Certificate (11):
* TLSv1.3 (OUT), TLS handshake, CERT verify (15):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
< HTTP/1.1 200 OK
< Date: Fri, 14 Jun 2024 20:43:02 GMT
< Server: Apache
< Content-Length: 829
< Content-Type: text/html;charset=ISO-8859-1
<
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html>
<head>
<title>Index of /example-main</title>
</head>
<body>
<h1>Index of /example-main</h1>
<pre><img src="/icons/blank.gif" alt="Icon "> <a href="?C=N;O=D">Name</a> <a href="?C=M;O=A">Last modified</a> <a href="?C=S;O=A">Size</a> <a href="?C=D;O=A">Description</a><hr><img src="/icons/back.gif" alt="[PARENTDIR]"> <a href="/">Parent Directory</a> -
<img src="/icons/folder.gif" alt="[DIR]"> <a href="15.5/">15.5/</a> 2024-06-11 19:21 -
<img src="/icons/folder.gif" alt="[DIR]"> <a href="15.6/">15.6/</a> 2024-06-11 19:20 -
<hr></pre>
</body></html>
* Connection #0 to host repo.example.org left intact
But when it comes to zypper (which is using curl too as far as I know) the first try to authenticate against the sever to download a rpm will fail (not always but very often), the second one is always successfully. That drives me crazy and is a bit annoying in terms of scripting (zypper -n in ... which will fail).
zypper ref has also no issues.
