apt-https-method-example.conf 8.3 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187
  1. /* This file is a sample configuration for apt https method. Configuration
  2. parameters found in this example file are expected to be used in main
  3. apt.conf file, just like other configuration parameters for different
  4. methods (ftp, file, ...).
  5. This example file starts with a common setup that voluntarily exhibits
  6. all available configurations knobs with simple comments. Extended
  7. comments on the behavior of the option is provided at the end for
  8. better readability. As a matter of fact, a common configuration file
  9. will certainly contain far less elements and benefit of default values
  10. for many parameters.
  11. Because some configuration parameters for apt https method in following
  12. examples apply to specific (fictional) repositories, the associated
  13. sources.list file is provided here:
  14. ...
  15. deb https://secure.dom1.tld/debian unstable main contrib non-free
  16. deb-src https://secure.dom1.tld/debian unstable main contrib non-free
  17. deb https://secure.dom2.tld/debian unstable main contrib non-free
  18. deb-src https://secure.dom2.tld/debian unstable main contrib non-free
  19. ...
  20. Some notes on the servers:
  21. - secure.dom1.tld is freely accessible using https (no client
  22. authentication is required).
  23. - secure.dom1.tld certificate is part of a multi level PKI, and we
  24. want to specifically check the issuer of its certificate. We do
  25. not have the constraint for secure.dom2.tld
  26. - secure.dom2.tld requires client authentication by certificate
  27. to access its content.
  28. - The certificate presented by both server have (as expected) a CN that
  29. matches their respective DNS names.
  30. - We have CRL available for both dom1.tld and dom2.tld PKI, and intend
  31. to use them.
  32. - It sometimes happens that we had other more generic https available
  33. repository to our list. We want the checks to be performed against
  34. a common list of anchors (like the one provided by ca-certificates
  35. package for instance)
  36. The sample configuration below basically covers those simple needs.
  37. */
  38. // Verify peer certificate and also matching between certificate name
  39. // and server name as provided in sources.list (default values)
  40. Acquire::https::Verify-Peer "true";
  41. Acquire::https::Verify-Host "true";
  42. // Except otherwise specified, use that list of anchors
  43. Acquire::https::CaInfo "/etc/ssl/certs/ca-certificates.pem";
  44. // Use a specific anchor and associated CRL. Enforce issuer of
  45. // server certificate using its cert.
  46. Acquire::https::secure.dom1.tld::CaInfo "/etc/apt/certs/ca-dom1-crt.pem";
  47. Acquire::https::secure.dom1.tld::CrlFile "/etc/apt/certs/ca-dom1-crl.pem";
  48. Acquire::https::secure.dom1.tld::IssuerCert "/etc/apt/certs/secure.dom1-issuer-crt.pem";
  49. // Like previous for anchor and CRL, but also provide our
  50. // certificate and keys for client authentication.
  51. Acquire::https::secure.dom2.tld::CaInfo "/etc/apt/certs/ca-dom2-crt.pem";
  52. Acquire::https::secure.dom2.tld::CrlFile "/etc/apt/certs/ca-dom2-crl.pem";
  53. Acquire::https::secure.dom2.tld::SslCert "/etc/apt/certs/my-crt.pem";
  54. Acquire::https::secure.dom2.tld::SslKey "/etc/apt/certs/my-key.pem";
  55. // No need to downgrade, TLS will be proposed by default. Uncomment
  56. // to have SSLv3 proposed.
  57. // Acquire::https::mirror.ipv6.ssi.corp::SslForceVersion "SSLv3";
  58. // No need for more debug if every is fine (default). Uncomment
  59. // me to get additional information.
  60. // Debug::Acquire::https "true";
  61. /*
  62. Options with extended comments:
  63. Acquire::https[::repo.domain.tld]::CaInfo "/path/to/ca/certs.pem";
  64. A string providing the path of a file containing the list of trusted
  65. CA certificates used to verify the server certificate. The pointed
  66. file is made of the concatenation of the CA certificates (in
  67. PEM format) creating the chain used for the verification of the path
  68. from the root (self signed one). If the remote server provides the
  69. whole chain during the exchange, the file need only contain the root
  70. certificate. Otherwise, the whole chain is required.
  71. If you need to support multiple authorities, the only way is to
  72. concatenate everything.
  73. If None is provided, the default CA bundle used by GnuTLS (apt https
  74. method is linked against libcurl-gnutls) is used. At the time of
  75. writing, /etc/ssl/certs/ca-certificates.crt.
  76. If no specific hostname is provided, the file is used by default
  77. for all https targets. If a specific mirror is provided, it is
  78. used for the https entries in the sources.list file that use that
  79. repository (with the same name).
  80. Acquire::https[::repo.domain.tld]::CrlFile "/path/to/all/crl.pem";
  81. Like previous knob but for passing the list of CRL files (in PEM
  82. format) to be used to verify revocation status. Again, if the
  83. option is defined with no specific mirror (probably makes little
  84. sense), this CRL information is used for all defined https entries
  85. in sources.list file. In a mirror specific context, it only applies
  86. to that mirror.
  87. Acquire::https[::repo.domain.tld]::IssuerCert "/path/to/issuer/cert.pem";
  88. Allows to constrain the issuer of the server certificate (for all
  89. https mirrors or a specific one) to a specific issuer. If the
  90. server certificate has not been issued by this certificate,
  91. connection fails.
  92. Acquire::https[::repo.domain.tld]::Verify-Peer "true";
  93. When authenticating the server, if the certificate verification fails
  94. for some reason (expired, revoked, man in the middle, lack of anchor,
  95. ...), the connection fails. This is obviously what you want in all
  96. cases and what the default value (true) of this option provides.
  97. If you know EXACTLY what you are doing, setting this option to "false"
  98. allow you to skip peer certificate verification and make the exchange
  99. succeed. Again, this option is for debugging or testing purpose only.
  100. It removes ALL the security provided by the use of SSL.TLS to secure
  101. the HTTP exchanges.
  102. Acquire::https[::repo.domain.tld]::Verify-Host "true";
  103. The certificate provided by the server during the TLS/SSL exchange
  104. provides the identity of the server which should match the DNS name
  105. used to access it. By default, as requested by RFC 2818, the name
  106. of the mirror is checked against the identity found in the
  107. certificate. This default behavior is safe and should not be
  108. changed. If you know that the server you are using has a DNS name
  109. which does not match the identity in its certificate, you can
  110. [report that issue to its administrator or] set the option to
  111. "false", which will prevent the comparison to be done.
  112. The options can be set globally or on a per-mirror basis. If set
  113. globally, the DNS name used is the one found in the sources.list
  114. file in the https URI.
  115. Acquire::https[::repo.domain.tld]::SslCert "/path/to/client/cert.pem";
  116. Acquire::https[::repo.domain.tld]::SslKey "/path/to/client/key.pem";
  117. These two options provides support for client authentication using
  118. certificates. They respectively accept the X.509 client certificate
  119. in PEM format and the associated client key in PEM format (non
  120. encrypted form).
  121. The options can be set globally (which rarely makes sense) or on a
  122. per-mirror basis.
  123. Acquire::https[::repo.domain.tld]::SslForceVersion "TLSv1";
  124. This option can be use to select the version which will be proposed
  125. to the server. "SSLv3" and "TLSv1" are supported. SSLv2, which is
  126. considered insecure anyway is not supported (by gnutls, which is
  127. used by libcurl against which apt https method is linked).
  128. When the option is set to "SSLv3" to have apt propose SSLv3 (and
  129. associated sets of ciphersuites) instead of TLSv1 (the default)
  130. when performing the exchange. This prevents the server to select
  131. TLSv1 and use associated ciphersuites. You should probably not use
  132. this option except if you know exactly what you are doing.
  133. Note that the default setting does not guarantee that the server
  134. will not select SSLv3 (for ciphersuites and SSL/TLS version as
  135. selection is always done by the server, in the end). It only means
  136. that apt will not advertise TLS support.
  137. Debug::Acquire::https "true";
  138. This option can be used to show debug information. Because it is
  139. quite verbose, it is mainly useful to debug problems in case of
  140. failure to connect to a server for some reason. The default value
  141. is "false".
  142. */