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

[stevemcqueen at mailinator.com]

On Fri, 4 Aug 2023 09:44:49 +0100 Simon McVittie <smcv at debian.org> wrote:
> 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

I figured it out. Turns out the OS installer, for whatever reason, didn't set up
my system time or hardware clock correctly. I was exactly 24 hours ahead and
didn't notice that. I installed and synced ntp, then synced my hardware clock, 
rebooted just to be sure. After that, the flatpak command worked just fine.

Apologies for the false alarm, and thank you for your help!

-------------- next part --------------

On Fri, 4 Aug 2023 09:44:49 +0100 Simon McVittie <smcv at debian.org> wrote:
> 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

I figured it out. Turns out the OS installer, for whatever reason, didn't set up
my system time or hardware clock correctly. I was exactly 24 hours ahead and
didn't notice that. I installed and synced ntp, then synced my hardware clock, 
rebooted just to be sure. After that, the flatpak command worked just fine.

Apologies for the false alarm, and thank you for your help!