Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

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

1,760 views
Skip to first unread message

Steve Mcqueen

unread,
Aug 3, 2023, 11:10:04 PM8/3/23
to
Package: flatpak
Version: 1.14.4-1
Severity: important
X-Debbugs-Cc: stevem...@mailinator.com

Dear Maintainer,

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.

Manually downloading the .flatpakrepo file and installing that way gets
a little further, but complains again the same way when trying to
download another metadata file.

So this may not be flatpak related, but maybe something to do with
ca-certificates or curl or something like that? Expired root CA or
something? This is the edge of my knowledge.

The end result of this is that I cannot use flatpak in Debian bookworm
because I cannot add the main remote repository from flathub.

-- Package-specific info:
Permissions of /usr/bin/bwrap:
-rwxr-xr-x 1 root root 72080 Feb 28 02:38 /usr/bin/bwrap
/etc/sysctl.d/*-bubblewrap.conf:
cat: '/etc/sysctl.d/*-bubblewrap.conf': No such file or directory
/usr/lib/sysctl.d/50-bubblewrap.conf:
# Enable unprivileged creation of new user namespaces in older Debian
# kernels.
#
# If this is not desired, copy this file to
# /etc/sysctl.d/50-bubblewrap.conf and change the value of this parameter
# to 0, then use dpkg-statoverride to make /usr/bin/bwrap setuid root.
#
# For more details see https://deb.li/bubblewrap or
# /usr/share/doc/bubblewrap/README.Debian
kernel.unprivileged_userns_clone=1
/proc/sys/kernel/unprivileged_userns_clone:
1
/proc/sys/user/max_cgroup_namespaces:
126235
/proc/sys/user/max_ipc_namespaces:
126235
/proc/sys/user/max_mnt_namespaces:
126235
/proc/sys/user/max_net_namespaces:
126235
/proc/sys/user/max_pid_namespaces:
126235
/proc/sys/user/max_time_namespaces:
126235
/proc/sys/user/max_user_namespaces:
126235
/proc/sys/user/max_uts_namespaces:
126235

-- System Information:
Debian Release: 12.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-10-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages flatpak depends on:
ii adduser 3.134
ii bubblewrap 0.8.0-2
ii dbus [default-dbus-system-bus] 1.14.8-2~deb12u1
ii fuse3 3.14.0-4
ii libappstream4 0.16.1-2
ii libarchive13 3.6.2-1
ii libc6 2.36-9+deb12u1
ii libcurl3-gnutls 7.88.1-10+deb12u1
ii libdconf1 0.40.0-4
ii libfuse3-3 3.14.0-4
ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1
ii libglib2.0-0 2.74.6-2
ii libgpgme11 1.18.0-3+b1
ii libjson-glib-1.0-0 1.6.6-1
ii libmalcontent-0-0 0.11.0-4
ii libostree-1-1 2022.7-2
ii libpolkit-agent-1-0 122-3
ii libpolkit-gobject-1-0 122-3
ii libseccomp2 2.5.4-1+b3
ii libsystemd0 252.12-1~deb12u1
ii libxau6 1:1.0.9-1
ii libxml2 2.9.14+dfsg-1.3~deb12u1
ii libzstd1 1.5.4+dfsg2-5
ii xdg-dbus-proxy 0.1.4-3

Versions of packages flatpak recommends:
ii ca-certificates 20230311
ii desktop-file-utils 0.26-1
ii gtk-update-icon-cache 3.24.37-2
ii hicolor-icon-theme 0.17-2
ii libpam-systemd 252.12-1~deb12u1
ii p11-kit 0.24.1-2
ii polkitd 122-3
ii shared-mime-info 2.2-1
ii xdg-desktop-portal 1.16.0-2
ii xdg-desktop-portal-gtk [xdg-desktop-portal-backend] 1.14.1-1
ii xdg-desktop-portal-kde [xdg-desktop-portal-backend] 5.27.5-2
ii xdg-user-dirs 0.18-1

Versions of packages flatpak suggests:
ii avahi-daemon 0.8-10
pn malcontent-gui <none>

Versions of packages bubblewrap depends on:
ii libc6 2.36-9+deb12u1
ii libcap2 1:2.66-4
ii libselinux1 3.4-1+b6

Versions of packages bubblewrap recommends:
ii procps 2:4.0.2-3

-- no debconf information

stevem...@mailinator.com

unread,
Aug 4, 2023, 2:40:04 PM8/4/23
to

On Fri, 4 Aug 2023 09:44:49 +0100 Simon McVittie <sm...@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!

0 new messages