APT-TRANSPORT-HTTP(1) APT APT-TRANSPORT-HTTP(1) NOM apt-transport-https - Le transport d'APT pour telecharger par HTTPS (protocole de transfert hypertexte securise) DESCRIPTION Ce transport d'APT permet d'utiliser les depots auxquels on accede au moyen de HTTPS (protocole HTTP Secure), aussi appele HTTP sur TLS. Il est disponible par defaut depuis apt 1.5 et etait disponible auparavant dans le paquet apt-transport-https. Veuillez noter qu'un transport n'est jamais appele directement par l'utilisateur, mais utilise par les outils d'APT s'appuyant sur la configuration de l'utilisateur. HTTP est un protocole de transport non chiffre (comparez avec apt- transport-http(1)), qui, comme l'indique le S ajoute, est enveloppe dans une couche chiffree, connue sous le nom de << Transport Layer Security >> (TLS), pour fournir un chiffrement de bout en bout. Un attaquant suffisamment competent peut encore observer les partenaires de la communication et une analyse approfondie de la communication chiffree pourrait toujours reveler des details importants. Un apercu des methodes de transport alternatives disponibles est donne dans sources.list(5). OPTIONS Le protocole HTTPS est base sur le protocole HTTP, aussi toutes les options prises en charge par apt-transport-http(1) sont aussi disponibles au moyen de Acquire::https et ont par defaut les memes valeurs que celles specifiees pour Acquire::http. Cette page de manuel ne documentera que les options propres a https. Accreditations du serveur 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::host::CAInfo. 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::host::CRLFile. As with the previous option, a file in PEM format needs to be specified. Desactiver la securite Durant l'authentification du serveur, si la verification du certificat echoue pour une raison quelconque (expire, revoque, homme du milieu, etc.), la connexion echoue. C'est certainement ce que vous souhaitez dans tous les cas et ce que fournit la valeur par defaut (<< true >>) de l'option Acquire::https::Verify-Peer et de ses variantes specifiques a l'hote. Si vous savez exactement ce que vous faites, la configuration de cette option a << false >> vous permet d'ignorer la verification du certificat du pair et de faire reussir l'echange. Une fois de plus, cette option est seulement destinee au test ou au debogage dans la mesure ou elle supprime toute la securite apportee par l'utilisation de HTTPS. De la meme facon, l'option Acquire::https::Verify-Host et sa variante specifique a l'hote peuvent etre utilisees pour desactiver la fonction de securite. Le certificat fourni par le serveur comprend l'identite du serveur qui devrait correspondre au nom de DNS utilise pour y acceder. Par defaut, comme cela est requis par la RFC 2818, le nom du miroir est verifie par rapport a l'identite trouvee dans le certificat. Ce comportement par defaut est sur et ne devrait pas etre modifie, mais si vous savez que le serveur que vous utilisez a un nom de DNS qui ne correspond pas a l'identite de son certificat, il est possible de regler l'option a "false", ce qui empechera la realisation de la comparaison. Authentification du client Outre la gestion de l'authentification basee sur les mots de passe (voir apt_auth.conf(5)) HTTPS prend aussi en charge l'authentification basee sur les certificats du client avec Acquire::https::SSLCert et Acquire::https::SSLKey. Leurs valeurs doivent etre respectivement celle du nom de fichier du certificat X.509 du client et celle de la clef privee (non chiffree) associee, toutes les deux au format PEM. En pratique, l'utilisation des variantes specifiques a l'hote des deux options est fortement recommandee. EXEMPLES 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"; Verify-Host::broken.example.org "false"; SSLCert::example.org "/path/to/client/cert.pem"; SSLKey::example.org "/path/to/client/key.pem" }; VOIR AUSSI apt-transport-http(1) apt.conf(5) apt_auth.conf(5) sources.list(5) BOGUES Page des bogues d'APT[1]. Si vous souhaitez signaler un bogue a propos d'APT, veuillez lire /usr/share/doc/debian/bug-reporting.txt ou utiliser la commande reportbug(1). TRADUCTEURS Jerome Marant, Philippe Batailler, Christian Perrier (2000, 2005, 2009, 2010), bubu et Jean-Pierre Giraud (2004, 2017-2024) et l'equipe de traduction francophone de Debian Veuillez noter que cette traduction peut contenir des parties non traduites. Cela est volontaire, pour eviter de perdre du contenu quand la traduction est legerement en retard sur le contenu d'origine. AUTEUR Equipe de developpement d'APT NOTES 1. Page des bogues d'APT https://bugs.debian.org/src:apt APT 3.1.13 04 janvier 2026 APT-TRANSPORT-HTTP(1)