Bug#1042999: flatpak: remote-add'ing flathub fails with error: SSL peer certificate or SSH remote key was not OK

[Simon McVittie]

On Fri, 04 Aug 2023 at 21:03:48 -0600, Steve Mcqueen wrote:
> From a new install of Debian bookworm, i'm attempting to install flatpak
> and flathub for the first time. I run the remote-add command and get
> back an ssl error. example:
> 
> $ flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
> error: Can't load uri https://flathub.org/repo/flathub.flatpakrepo: While fetching https://flathub.org/repo/flathub.flatpakrepo: [60] SSL peer certificate or SSH remote key was not OK
> 
> That flathub URL is a 301 redirect to: https://dl.flathub.org/repo/flathub.flatpakrepo
> 
> As far as I can tell there's nothing wrong with the certs on flathub's
> end. I tried a few random online SSL validators and they gave no
> complaints. The cert isn't expired, and is properly chained. directly 
> using curl doesn't seem to complain. Firefox doesn't complain. 
> Interestingly, wget DOES complain about the url, saying the certificate
> is not trusted. 

The curl(1) command-line tool uses libcurl4 (libcurl with OpenSSL),
but flatpak uses libcurl3-gnutls (libcurl with GNUTLS), and wget also
uses GNUTLS. I suspect this means that there is something about the
flathub.org or dl.flathub.org certificate chain as seen from your network
that OpenSSL has no problem with, but GNUTLS considers to be a problem.

Are you on a network that is restricted, behind a transparent proxy or
unusual in any other way?

These commands might help to find what is happening (openssl and gnutls-bin
packages required):

openssl s_client -showcerts -connect flathub.org:443 </dev/null
openssl s_client -showcerts -connect dl.flathub.org:443 </dev/null
gnutls-cli -p443 flathub.org </dev/null
gnutls-cli -p443 dl.flathub.org </dev/null

The output of all of them looks reasonable to me (attached for reference),
and they all say "Verification: OK" or "Status: The certificate is
trusted"; but I also can't reproduce any problem with flatpak(1), so their
results for someone who *can* reproduce a problem would be more useful.

curl maintainers: should flatpak be preferring libcurl4-openssl-dev
instead of libcurl4-gnutls-dev, now that the ftp team have announced
that they consider that to be acceptable for (L)GPL packages?

    smcv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openssl-dl.flathub.org.log.gz
Type: application/gzip
Size: 4086 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnutls-maint/attachments/20230804/ad8fd295/attachment.gz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openssl-flathub.org.log.gz
Type: application/gzip
Size: 4078 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnutls-maint/attachments/20230804/ad8fd295/attachment-0001.gz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnutls-dl.flathub.org.log.gz
Type: application/gzip
Size: 863 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnutls-maint/attachments/20230804/ad8fd295/attachment-0002.gz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnutls-flathub.org.log.gz
Type: application/gzip
Size: 857 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnutls-maint/attachments/20230804/ad8fd295/attachment-0003.gz>