I'm using apt-cacher-ng (running on a different system) with SSL
passthrough. It works fine for the official Debian repositories, and for
some third-party ones, but fails for other third-party ones:

~# apt update
Ign:1 https://deb.torproject.org/torproject.org sid InRelease
Ign:2 https://repository.mullvad.net/deb/stable trixie InRelease
Hit:3 http://deb.debian.org/debian sid InRelease
Hit:4 https://dl.winehq.org/wine-builds/debian bullseye InRelease
Hit:5 https://packages.element.io/debian default InRelease
Ign:2 https://repository.mullvad.net/deb/stable trixie InRelease
Ign:1 https://deb.torproject.org/torproject.org sid InRelease
Ign:2 https://repository.mullvad.net/deb/stable trixie InRelease
Ign:1 https://deb.torproject.org/torproject.org sid InRelease
Err:2 https://repository.mullvad.net/deb/stable trixie InRelease
  Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown.  Could not handshake: Error in the certificate verification. [IP: xx.xx.xx.xx 3142]
Err:1 https://deb.torproject.org/torproject.org sid InRelease
  Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown.  Could not handshake: Error in the certificate verification. [IP: xx.xx.xx.xx 3142]
All packages are up to date.
Warning: Failed to fetch https://repository.mullvad.net/deb/stable/dists/trixie/InRelease  Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown.  Could not handshake: Error in the certificate verification. [IP: xx.xx.xx.xx 3142]
Warning: Failed to fetch https://deb.torproject.org/torproject.org/dists/sid/InRelease  Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown.  Could not handshake: Error in the certificate verification. [IP: xx.xx.xx.xx 3142]
Warning: Some index files failed to download. They have been ignored, or old ones used instead.

(All repositories work fine with a direct connection, without
apt-cacher-ng.)

I first encountered this a couple of years ago:

https://lists.debian.org/debian-user/2022/05/msg00084.html

At the time I thought that it might have had to do with the fact that
the Tor site used a CNAME, and was related to this:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986356

but now I'm experiencing the same problem with the Mullvad site, which
does not use a CNAME.

Hello,

One primary purpose of SSL is to prevent MITM attacks on communication between
client and server.  What apt-cacher-ng does is precisely equivalent to that, so
it's properly impossible to fix this "bug".

The solution is to not use SSL: the gpg-signed release files will indeed verify
the authenticity of the downloaded packages, and the expiration dates will
confirm that the packages downloaded are not (too) out of date.

SSL also provides some privacy (i.e., obscuring the packages that are being
downloaded somewhat).  That is unfortunately not something that can be
reasonably provided by this package, since by its nature the cacher will know
what you request of it (and, more fatally, that you are requesting anything
of it).

Best,
Antonio Russo

Hi! Thank you for your work on Debian.

I'd agree with your point if the apt-cacher-ng documentation would
say:

"Due to the nature of the SSL/TLS/HTTPS protocols, apt-cacher-ng
does not support SSL/TLS remotes."

But what it actually says is:

"... there are three (and a half) methods to use SSL. ... The
"laissez-faire method": in acng.conf (or related) configure the
PassThroughPattern option to contain a regex like .* and configure the
clients to use apt-cacher-ng as HTTP proxy and let the clients connect
to https URLs "as usual"."

https://www.unix-ag.uni-kl.de/~bloch/acng/html/howtos.html#ssluse

So insofar as this method (sometimes) does not work and throws an error,
this is a bug.

This solution is not available to me - I'm just a user, and I don't
control the repositories in question.