APT-TRANSPORT-HTTP(1)

📦
version 3.3.5 · 14 versions
, in arch rolling, nixpkgs unstable

💅 apt-transport-https (from the APT manual, section 1) 🎀

okay so bestie, buckle up — this is the page for apt-transport-https, and it's genuinely iconic once you get it. it lives in section 1 of the APT manual, so like, it's a command-ish page, but plot twist: you never actually type it yourself. iykyk. ✨

🌸 NAME 🌸

apt-transport-https — the APT transport for downloading stuff over the HTTP Secure protocol (HTTPS). that's it, that's the whole name, and it ate. 💅

🦋 SYNOPSIS 🦋

honestly there isn't a classic one-line synopsis here — the NAME line is the whole vibe. it's a transport, not a command, so there's no argument list to memorize. moving on, babe. 🫶

✨ DESCRIPTION ✨

so this APT transport is what lets you use repositories that you access via the HTTP Secure protocol (HTTPS), which is also called HTTP over TLS, because we love an alias. 🌈

the way that it's available by default since apt 1.5, and before that it was chilling in the package apt-transport-https. iconic glow-up. 👑

important vibe check: a transport is never called directly by a user — it gets used by APT tools based on your user configuration. so don't try to run it like a main character, it's more of a backstage legend. 🌟

here's the science part, and no cap it matters: HTTP by itself is an unencrypted transport protocol (compare apt-transport-http(1)), which — as the appended S is literally telling you — gets wrapped in an encrypted layer known as Transport Layer Security (TLS) to give you end-to-end encryption. 🔥

but 💀 real talk, a sufficiently capable attacker can still observe the communication partners, and deeper analysis of that encrypted communication might still reveal important details. so it's not a magic invisibility cloak, bestie. an overview over the available alternative transport methods is given in sources.list(5). go read it, i'll wait. 🍓

🌼 OPTIONS 🌼

the HTTPS protocol is based on the HTTP protocol, so literally all options supported by apt-transport-http(1) are also available via Acquire::https, and they'll default to the same values specified for Acquire::http. slay, inheritance. 💖

this manpage is only gonna document the options that are unique to https, because duplicating the whole other page would be, like, so much. 🙈

🔐 Server credentials 🔐

by default, all certificates trusted by the system (see the ca-certificates package) are used for the verification of the server certificate. very much the "trust the system" era.

  • Acquire::https::CAInfo and its host-specific friend Acquire::https::host::CAInfo — configure an alternative certificate authority (CA). the CAInfo option specifies a file made up of CA certificates (in PEM format) concatenated together, and that creates the chain which APT should use to verify the path from your self-signed root certificate. 🧚
    • if the remote server provides the whole chain during the exchange, the file need only contain the root certificate.
    • otherwise, the whole chain is required. no shortcuts, sorry.
    • if you need to support multiple authorities, the only way is to concatenate everything. that's the rule, periodt. 👑
  • Acquire::https::CRLFile and Acquire::https::host::CRLFile — configure a custom certificate revocation list (CRL). same energy as the previous option: a file in PEM format needs to be specified.

🚨 Disabling security (careful, bestie) 🚨

during server authentication, if certificate verification fails for some reason — expired, revoked, man in the middle, etc. — the connection fails. and honestly? that's obviously what you want in all cases, and it's exactly what the default value (true) of the option Acquire::https::Verify-Peer and its host-specific variant provides. 🫶

⚠️ danger zone: if you know exactly what you are doing, setting this option to "false" allows you to skip peer certificate verification and make the exchange succeed. but again — this option is for debugging or testing purposes only, because it removes all security provided by the use of HTTPS. like, all of it. 💀

similarly, the option Acquire::https::Verify-Host and its host-specific variant can be used to deactivate a security feature. here's the tea: the certificate provided by the server includes the identity of the server, which should match the DNS name used to access it. by default — as requested by RFC 2818 — the name of the mirror is checked against the identity found in the certificate. this default behavior is safe and should not be changed. 😭

but if you know that the server you're using has a DNS name which does not match the identity in its certificate, you can set the option to "false", which will prevent the comparison from being performed. your choice, your consequences, i'm just the messenger. 🙈

🎀 Client authentication 🎀

besides supporting password-based authentication (see apt_auth.conf(5)), HTTPS also supports authentication based on client certificates, via:

  • Acquire::https::SSLCert
  • Acquire::https::SSLKey

these should be set respectively to the filename of the X.509 client certificate and the associated (unencrypted) private key — both in PEM format. 🔐

and in practice, the use of the host-specific variants of both options is highly recommended. like, highly. take the advice, babe. ✨

🌈 EXAMPLES 🌈

here's a whole mood-board of config, copy it exactly, don't touch the syntax:

Acquire::https {
     Proxy::example.org "DIRECT";
     Proxy "socks5h://apt:pass@127.0.0.1:9050";
     Proxy-Auto-Detect "/usr/local/bin/apt-https-proxy-auto-detect";
     No-Cache "true";
     Max-Age "3600";
     No-Store "true";
     Timeout "10";
     Dl-Limit "42";
     Pipeline-Depth "0";
     AllowRedirect "false";
     User-Agent "My APT-HTTPS";
     SendAccept "false";

     CAInfo "/path/to/ca/certs.pem";
     CRLFile "/path/to/all/crl.pem";
     Verify-Peer "true";
     broken.example.org::Verify-Host "false";
     example.org::SSLCert "/path/to/client/cert.pem";
     example.org::SSLKey "/path/to/client/key.pem"
};

like, look at all those host-specific overrides. obsessed. 🔥

🦋 SEE ALSO 🦋

the whole friend group, fr fr. 🫶

💀 BUGS 💀

found a bug? the APT bug page[1] is the place. and if you wish to report a bug in APT, please see /usr/share/doc/debian/bug-reporting.txt or the reportbug(1) command. do it properly and the maintainers will love you for it. 💖

👑 AUTHOR 👑

APT team. the icons themselves. 🌟

🎀 NOTES 🎀

  1. APT bug page — https://bugs.debian.org/src:apt

and that's the whole page, bestie! 🧚 this beauty is from APT 3.3.5, dated 13 May 2026 — so go forth, use HTTPS, verify your peers, and please don't set Verify-Peer to "false" unless you're literally debugging. love u, stay secure 💜✨

📦 where this page comes from