summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
Diffstat (limited to 'doc')
-rw-r--r--doc/examples/apt-https-method-example.conf165
1 files changed, 165 insertions, 0 deletions
diff --git a/doc/examples/apt-https-method-example.conf b/doc/examples/apt-https-method-example.conf
new file mode 100644
index 000000000..0067171bd
--- /dev/null
+++ b/doc/examples/apt-https-method-example.conf
@@ -0,0 +1,165 @@
+/* This file is a sample configuration for apt https method. Configuration
+ parameters found in this example file are expected to be used in main
+ apt.conf file, just like other configuration parameters for different
+ methods (ftp, file, ...).
+
+ This example file starts with a common setup that voluntarily exhibits
+ all available configurations knobs with simple comments. Extended
+ comments on the behavior of the option is provided at the end for
+ better readibility. As a matter of fact, a common configuration file
+ will certainly contain far less elements and benefit of default values
+ for many parameters.
+
+ Because some configuration parameters for apt https method in following
+ examples apply to specific (fictional) repositories, the associated
+ sources.list file is provided here:
+
+ ...
+
+ deb https://secure.dom1.tld/debian unstable main contrib non-free
+ deb-src https://secure.dom1.tld/debian unstable main contrib non-free
+
+ deb https://secure.dom2.tld/debian unstable main contrib non-free
+ deb-src https://secure.dom2.tld/debian unstable main contrib non-free
+
+ ...
+
+
+ Some notes on the servers:
+
+ - secure.dom1.tld is freely accessible using https (no client
+ authentication is required).
+ - secure.dom1.tld certificate is part of a multi level PKI, and we
+ want to specifically check the issuer of its certificate. We do
+ not have the constraint for secure.dom2.tld
+ - secure.dom2.tld requires client authentication by certificate
+ to access its content.
+ - The certificate presented by both server have (as expected) a CN that
+ matches their respective DNS names.
+ - It somtimes happens that we had other more generic https available
+ repository to our list. We want the checks to be performed against
+ a common list of anchors (like the one provided by ca-certificates
+ package for instance)
+
+ The sample configuration below basically covers those simpe needs.
+*/
+
+
+// Verify peer certificate and also matching between certificate name
+// and server name as provided in sources.list (default values)
+Acquire::https::Verify-Peer "true";
+Acquire::https::Verify-Host "true";
+
+// Except otherwise specified, use that list of anchors
+Acquire::https::CaInfo "/etc/ssl/certs/ca-certificates.pem";
+
+// Use a specific anchor and associated CRL. Enforce issuer of
+// server certificate using its cert.
+Acquire::https::secure.dom1.tld::CaInfo "/etc/apt/certs/ca-dom1-crt.pem";
+
+// Like previous for anchor and CRL, but also provide our
+// certificate and keys for client authentication.
+Acquire::https::secure.dom2.tld::CaInfo "/etc/apt/certs/ca-dom2-crt.pem";
+Acquire::https::secure.dom2.tld::SslCert "/etc/apt/certs/my-crt.pem";
+Acquire::https::secure.dom2.tld::SslKey "/etc/apt/certs/my-key.pem";
+
+// No need to downgrade, TLS will be proposed by default. Uncomment
+// to have SSLv3 proposed.
+// Acquire::https::mirror.ipv6.ssi.corp::SslForceVersion "SSLv3";
+
+// No need for more debug if every is fine (default). Uncomment
+// me to get additional information.
+// Debug::Acquire::https "true";
+
+
+/*
+ Options with extended comments:
+
+ Acquire::https[::repo.domain.tld]::CaInfo "/path/to/ca/certs.pem";
+
+ A string providing the path of a file containing the list of trusted
+ CA certificates used to verify the server certificate. The pointed
+ file is made of the concatenation of the CA certificates (in
+ PEM format) creating the chain used for the verification of the path
+ from the root (self signed one). 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.
+
+ If None is provided, the default CA bundle used by GnuTLS (apt https
+ method is linked against libcurl-gnutls) is used. At the time of
+ writing, /etc/ssl/certs/ca-certificates.crt.
+
+ If no specific hostname is provided, the file is used by default
+ for all https targets. If a specific mirror is provided, it is
+ used for the https entries in the sources.list file that use that
+ repository (with the same name).
+
+ Acquire::https[::repo.domain.tld]::Verify-Peer "true";
+
+ When authenticating the server, if the certificate verification fails
+ for some reason (expired, revoked, man in the middle, lack of anchor,
+ ...), the connection fails. This is obviously what you want in all
+ cases and what the default value (true) of this option provides.
+
+ If you know EXACTLY what you are doing, setting this option to "false"
+ allow you to skip peer certificate verification and make the exchange
+ succeed. Again, this option is for debugging or testing purpose only.
+ It removes ALL the security provided by the use of SSL.TLS to secure
+ the HTTP exchanges.
+
+ Acquire::https[::repo.domain.tld]::Verify-Host "true";
+
+ The certificate provided by the server during the TLS/SSL exchange
+ provides 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. If you know that the server you are using has a DNS name
+ which does not match the identity in its certificate, you can
+ [report that issue to its administrator or] set the option to
+ "false", which will prevent the comparison to be done.
+
+ The options can be set globally or on a per-mirror basis. If set
+ globally, the DNS name used is the one found in the sources.list
+ file in the https URI.
+
+ Acquire::https[::repo.domain.tld]::SslCert "/path/to/client/cert.pem";
+ Acquire::https[::repo.domain.tld]::SslKey "/path/to/client/key.pem";
+
+ These two options provides support for client authentication using
+ certificates. They respectively accept the X.509 client certificate
+ in PEM format and the associated client key in PEM format (non
+ encrypted form).
+
+ The options can be set globally (which rarely makes sense) or on a
+ per-mirror basis.
+
+ Acquire::https[::repo.domain.tld]::SslForceVersion "TLSv1";
+
+ This option can be use to select the version which will be proposed
+ to the server. "SSLv3" and "TLSv1" are supported. SSLv2, which is
+ considered insecure anyway is not supported (by gnutls, which is
+ used by libcurl against which apt https method is linked).
+
+ When the option is set to "SSLv3" to have apt propose SSLv3 (and
+ associated sets of ciphersuites) instead of TLSv1 (the default)
+ when performing the exchange. This prevents the server to select
+ TLSv1 and use associated cipheruites. You should probably not use
+ this option except if you know exactly what you are doing.
+
+ Note that the default setting does not guarantee that the server
+ will not select SSLv3 (for ciphersuites and SSL/TLS version as
+ selectio is always done by the server, in the end). It only means
+ that apt will not advertise TLS support.
+
+ Debug::Acquire::https "true";
+
+ This option can be used to show debug information. Because it is
+ quite verbose, it is mainly useful to debug problems in case of
+ failure to connect to a server for some reason. The default value
+ is "false".
+
+*/