Home / Alt manpages / apt-transport-https(1)

  • apt-transport-https(1)
  • User command
  • linux

Use APT HTTPS Repositories Safely on Ubuntu 24.04

By the end of this guide, APT will be able to fetch package metadata from an HTTPS repository while retaining the default TLS certificate and host-name checks. You will also know where to look when a private mirror fails. The examples target the installed APT 2.8.3 on Ubuntu 24.04 (Noble). Allow about 10 minutes, plus any time needed to obtain a correct CA certificate from whoever operates a private repository.

What this transport does

apt-transport-https is not a command you normally run. It is a transport selected by APT when a repository URL begins with https://. HTTPS wraps HTTP in TLS, so the connection is encrypted and the server is authenticated using certificates. The transport does not make package contents trustworthy by itself: APT's repository signatures and your normal package verification still matter.

APT has included this transport by default since version 1.5. On this machine it is provided by APT 2.8.3, so installing a separate package is unnecessary. The first checkpoint is to confirm what is installed:

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 reported by the second command. If your system is older than 1.5, consult its package manager documentation before assuming HTTPS is built in.

1. Check the repository URL before changing anything

Repository definitions are normally in /etc/apt/sources.list and files below /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 with https://, followed by the expected host name. Check for spelling mistakes, unexpected redirects and a distribution name that matches the repository operator's instructions. Do not 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 when you have a verified repository definition. Editing files under /etc/apt requires elevated privileges. The following example shows the shape of a separate list file; replace every placeholder with values supplied by the repository operator:

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'

Checkpoint: inspect the result before asking APT to use it.

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

Expected output is one line beginning deb https://packages.example.org/ubuntu noble main. The example creates or replaces that one file. If you used it with a real host and need to undo the change, remove only that file after checking that no other repository uses it:

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

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

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 does not upgrade or install packages:

sudo apt-get update

A successful HTTPS source ends with a fetched or hit index and no certificate error. If you need to confirm which transport APT selected, repeat the command with HTTPS acquisition debugging:

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 cause and 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 be given a PEM file containing its trusted root and, when necessary, intermediate certificates. The HTTPS transport option is Acquire::https::CAInfo; a host-specific form, Acquire::https::CAInfo::host, limits the setting to one host.

Prefer a small, host-specific configuration file rather than changing trust for every repository:

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'

Obtain the PEM file through a trusted administrative channel. Never accept a certificate merely 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 only after checking that 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

Acquire::https::Verify-Peer and Acquire::https::Verify-Host default to true. The first validates the certificate chain; the second checks that the certificate identifies the host name in the repository URL. Setting either to false permits an impersonated or intercepted server to look usable. The manpage permits this only for tightly controlled debugging or testing, not as a repair for a production repository. Remove any temporary override immediately after diagnosing the fault.

Done means

  • The repository URI starts with https:// and names the intended host.
  • APT 1.5 or newer is installed; this machine reports APT 2.8.3.
  • sudo apt-get update completes without TLS or certificate errors.
  • Default peer and host verification remain enabled.
  • Any private CA configuration is host-specific, documented and removable.