HTTPS and a VPN Do Not Authenticate the Package You Install

An update fails, and the suggestion in the thread runs along familiar lines: the traffic crosses a VPN, so the download must be trustworthy, and the signature check gets relaxed to get past the error. Two separate ideas have been merged into one sentence. Encryption protects a path between endpoints; authentication decides whether the bytes came from the publisher you intended. A tunnel supplies the first and says nothing about the second.

The symptom is usually a verification error on one host, in one repository, while everything else updates normally. That shape already tells you the network path is working and the disagreement is about trust.

Two controls that answer different questions

Transport security answers who is on the other end of this connection and whether anyone on the path can read or modify it. Package authentication answers whether this artifact was published by the authority you configured, and it has to survive being downloaded through a mirror you do not control.

Those questions overlap only at the edges. A correct certificate on a mirror proves the mirror is the mirror; it does not prove the mirror holds unmodified publisher content. A signed package proves the publisher signed it; it does not tell you the network delivered the newest version or that the repository you pointed at is the one your organisation approved.

The failure mode people create by disabling checks is a permanent loss of the second guarantee, in exchange for one successful download. That trade is invisible until the day it matters.

What apt actually authenticates

APT's model is an authenticated archive chain. Signed release metadata leads by checksum to the package indexes, and those indexes lead by checksum to the individual package files. Verifying the chain is what makes a mirror untrusted-but-usable: the mirror can serve anything it likes, and the metadata signature decides whether APT accepts it.

That is deliberately not the same as checking a maintainer signature on every installed package, and the distinction explains why "the package is signed" and "the archive is authenticated" get used interchangeably in bug reports when they mean different things.

apt-get update
apt-cache policy
apt-config dump | grep -iE 'AllowInsecure|AllowDowngrade'

Read the update output rather than the exit code alone. APT names the repository whose metadata failed, and that name is the boundary to investigate. A repository marked as trusted without signature verification, or an insecure-repository override, is a configuration decision someone made and should be able to explain.

Freshness is a separate property again. A validly signed metadata file can be older than the one you saw last week, which is why release metadata carries an expiry and why a clock problem on the client can produce verification failures that look like key problems.

What dnf5 checks separately

The RPM side exposes two distinct switches, and confusing them produces the same class of mistake in the other direction. One controls whether package files must carry a valid signature; the other controls whether repository metadata must be signed. They can be set independently, and a system can be strict about one while permissive about the other.

dnf5 config-manager --dump 2>/dev/null | grep -iE 'gpgcheck|repo_gpgcheck'
rpm -q --qf '%{NAME} %{SIGPGP:pgpsig}\n' bash

The package query shows what the installed copy's signature metadata looks like, which is a useful reality check against a configuration file that claims strictness. What it does not tell you is the distribution's supported policy, which is what you should be following rather than a generic "enable GPG" instruction from a forum.

Where the two managers differ, the difference is architectural rather than a sign that one is weaker. Both authenticate publisher content; they place the signature at different points in the chain.

What the tunnel does and does not add

A VPN can supply a required route, keep update traffic off an untrusted access network, and reduce what a local observer sees. Those are real operational benefits, and none of them is publisher authentication.

HTTPS adds its own guarantee, and it is narrower than it feels. It authenticates the TLS endpoint you connected to. If that endpoint is a mirror, you have authenticated the mirror, not the archive content it serves. This is precisely the case the signed-metadata chain exists to handle.

Neither control promises availability either. A network can deny delivery, and an authenticated object is not automatically the newest one. Use the package manager's own freshness policy instead of inferring it from the presence of a lock icon.

Diagnose the boundary that failed

Name the stage before changing anything: DNS resolution, the proxy or route, the TLS endpoint identity, archive authentication, package signature checks, or installation. Each has a distinct error shape and a distinct owner.

Repairing a network path should never involve declaring an unknown signing key trusted, ignoring certificates, or accepting a repository configuration you did not ask for. If a key genuinely rotated, the distribution or repository owner publishes the new key through a channel you can verify, and that is the correction to apply.

Write down which boundary failed and who owns it. The next update failure will be at a different boundary, and having the list makes it a five-minute diagnosis instead of another argument about whether the tunnel makes updates safe.