The HTTPS protocol is based on the HTTP protocol, so all options supported by apt-transport-http(1) are
also available via Acquire::https and will default to the same values specified for Acquire::http. This
manpage will only document the options uniquetohttps.
Servercredentials
By default all certificates trusted by the system (see ca-certificates package) are used for the
verification of the server certificate. An alternative certificate authority (CA) can be configured with
the Acquire::https::CAInfo option and its host-specific option Acquire::https::CAInfo::host. The CAInfo
option specifies a file made up of CA certificates (in PEM format) concatenated together to create 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. If you need to support multiple authorities, the only way is to
concatenate everything.
A custom certificate revocation list (CRL) can be configured with the options Acquire::https::CRLFile and
Acquire::https::CRLFile::host. As with the previous option, a file in PEM format needs to be specified.
Disablingsecurity
During server authentication, if certificate verification fails for some reason (expired, revoked, man in
the middle, etc.), the connection fails. This is obviously what you want in all cases and what the
default value (true) of the option Acquire::https::Verify-Peer and its host-specific variant provides. 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. Again, this option is for debugging or testing purposes only
as it removes all security provided by the use of HTTPS.
Similarly the option Acquire::https::Verify-Host and its host-specific variant can be used to deactivate
a security feature: 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 are 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.
Clientauthentication
Besides supporting password-based authentication (see apt_auth.conf(5)) HTTPS also supports
authentication based on client certificates via Acquire::https::SSLCert and 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. In practice the use of the host-specific variants of both
options is highly recommended.