Set Up apt-transport-https Without Weakening TLS

apt-transport-https lets APT fetch package metadata over an encrypted, certificate-checked connection. This shows you how to add an HTTPS repository properly, and where to look when a private mirror refuses to cooperate. Examples target the installed APT 2.8.3 on Ubuntu 24.04 (Noble). Allow about 10 minutes, plus any time needed to get a correct CA certificate from whoever runs a private repository.

What this transport does

apt-transport-https is not a command you run yourself. It is a transport APT selects when a repository URL starts https://. HTTPS wraps HTTP in TLS, so the connection is encrypted and the server is authenticated using certificates. It does not make package contents trustworthy on its own: APT's repository signatures and your normal package verification still matter just as much.

APT has included this transport by default since version 1.5. On this machine it comes from APT 2.8.3, so there is no separate package to install. The first checkpoint is confirming what you actually have:

apt-get --version | head -n 3
apt-cache policy apt | sed -n '1,8p'

You should see APT 2.8.3 and the installed package version from the second command. Running something older than 1.5? Check its package manager documentation before assuming HTTPS is built in.

1. Check the repository URL before changing anything

Repository definitions normally live in /etc/apt/sources.list and files under /etc/apt/sources.list.d/. Read the active definitions first; this is an ordinary, read-only command:

grep -RIn --include='*.list' --include='*.sources' '^[[:space:]]*deb ' \
  /etc/apt/sources.list /etc/apt/sources.list.d 2>/dev/null

For an HTTPS repository, the URI should start https://, followed by the host name you actually expect. Check for spelling mistakes, unexpected redirects, and a distribution name that matches the repository operator's instructions. Never paste passwords or private keys into a source URL: APT supports repository authentication separately, and credentials in URLs can leak through logs and process inspection.

2. Add or edit one repository carefully

Only change a source file once you have a verified repository definition. Editing files under /etc/apt needs elevated privileges. This shows the shape of a separate list file; replace every placeholder with values the repository operator actually supplied:

sudo install -m 0644 /dev/null /etc/apt/sources.list.d/example.list
sudo sh -c 'printf "%s\n" "deb https://packages.example.org/ubuntu noble main" > /etc/apt/sources.list.d/example.list'

sudo sed -n '1p' /etc/apt/sources.list.d/example.list

You should see one line beginning deb https://packages.example.org/ubuntu noble main. This creates or replaces that one file. If you used it against a real host and need to undo it, remove only that file, once you have checked nothing else depends on it:

sudo rm /etc/apt/sources.list.d/example.list

That removal is a state-changing operation. It does not uninstall any packages, but it does stop APT finding packages from that source until the definition comes back.

3. Refresh metadata and read the failure literally

Refresh package indexes with elevated privileges. This changes files in APT's local lists cache, but it never upgrades or installs a package by itself:

sudo apt-get update

A successful HTTPS source ends with a fetched or hit index and no certificate error. Need to confirm which transport APT actually picked? Repeat the command with HTTPS acquisition debugging on:

sudo apt-get -o Debug::Acquire::https=true update

Do not treat a failed TLS connection as a reason to disable verification. The usual causes are a wrong host name, an expired server certificate, an incomplete server chain, an inaccurate system clock, a proxy problem, or a missing private CA. Fix the actual cause, then run sudo apt-get update again.

Private certificate authorities

APT trusts certificates supplied by the system's ca-certificates package by default. A private repository can instead hand you a PEM file with its trusted root and, where needed, intermediate certificates. The HTTPS transport option is Acquire::https::CAInfo; a host-specific form, Acquire::https::CAInfo::host, limits it to one host.

Prefer a small, host-specific configuration file over changing trust for every repository at once:

sudo install -m 0644 /tmp/example-root-chain.pem /etc/apt/example-root-chain.pem
sudo sh -c 'printf "%s\n" \
  "Acquire::https::CAInfo::packages.example.org \"/etc/apt/example-root-chain.pem\";" \
  > /etc/apt/apt.conf.d/80-example-https'

Get the PEM file through a trusted administrative channel. Never accept a certificate just because a browser warning can be clicked through. Verify the configuration is readable, then retry the metadata refresh:

sudo apt-config dump | grep -F 'Acquire::https::CAInfo'
sudo apt-get update

The first command should print the host-specific path. If this change is no longer needed, remove the configuration and the certificate file, but only once you have checked nothing else depends on them:

sudo rm /etc/apt/apt.conf.d/80-example-https
sudo rm /etc/apt/example-root-chain.pem

Do not weaken TLS checks

Done means

• URI correct: the repository URI starts https:// and names the intended host.
• Version sufficient: APT 1.5 or newer is installed; this machine reports APT 2.8.3.
• Update clean: sudo apt-get update completes without TLS or certificate errors.
• Verification intact: default peer and host checks remain enabled.
• CA config scoped: any private CA setting is host-specific, documented and easy to remove.