Provided by: apt_3.1.3_amd64 
NOM
apt-transport-https - Le transport d'APT pour télécharger par HTTPS (protocole de transfert hypertexte
sécurisé)
DESCRIPTION
Ce transport d'APT permet d'utiliser les dépôts auxquels on accède au moyen de HTTPS (protocole HTTP
Secure), aussi appelé HTTP sur TLS. Il est disponible par défaut depuis apt 1.5 et était disponible
auparavant dans le paquet apt-transport-https. Veuillez noter qu'un transport n'est jamais appelé
directement par l'utilisateur, mais utilisé par les outils d'APT s'appuyant sur la configuration de
l'utilisateur.
HTTP est un protocole de transport non chiffré (comparez avec apt-transport-http(1)), qui, comme
l'indique le S ajouté, est enveloppé dans une couche chiffrée, connue sous le nom de « Transport Layer
Security » (TLS), pour fournir un chiffrement de bout en bout. Un attaquant suffisamment compétent peut
encore observer les partenaires de la communication et une analyse approfondie de la communication
chiffrée pourrait toujours révéler des détails importants. Un aperçu des méthodes de transport
alternatives disponibles est donné dans sources.list(5).
OPTIONS
Le protocole HTTPS est basé 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 défaut les mêmes valeurs
que celles spécifiées pour Acquire::http. Cette page de manuel ne documentera que les options propres à
https.
Accréditations du serveur
Par défaut, tous les certificats de confiance du système (voir le paquet ca-certificates sont utilisés
pour la vérification du certificat du serveur. Une autre autorité de certification (CA) peut être
configurée avec l'option Acquire::https::CAInfo et son option spécifique de l'hôte
Acquire::https::CAInfo::hôte. L'option CAInfo spécifie un fichier composé des certificats de CA (au
format PEM) concaténés pour créer la chaîne qu'APT peut utiliser pour vérifier le chemin à partir du
certificat racine auto-signée. Si le serveur distant fournit toute la chaîne pendant l'échange, le
fichier ne doit contenir que le certificat racine. Autrement, toute la chaîne est requise. Si la gestion
de plusieurs autorités est nécessaire, le seul moyen est de tout concaténer.
Une liste de révocation de certificats (CRL) personnalisée peut être configurée avec l'option
Acquire::https::CRLFile et Acquire::https::CRLFile::hôte. Comme avec l'option précédente, il faut
spécifier un fichier au format PEM.
Désactiver la sécurité
Durant l'authentification du serveur, si la vérification du certificat échoue pour une raison quelconque
(expiré, révoqué, homme du milieu, etc.), la connexion échoue. C'est certainement ce que vous souhaitez
dans tous les cas et ce que fournit la valeur par défaut (« true ») de l'option
Acquire::https::Verify-Peer et de ses variantes spécifiques à l'hôte. Si vous savez exactement ce que
vous faites, la configuration de cette option à « false » vous permet d'ignorer la vérification du
certificat du pair et de faire réussir l'échange. Une fois de plus, cette option est seulement destinée
au test ou au débogage dans la mesure où elle supprime toute la sécurité apportée par l'utilisation de
HTTPS.
De la même façon, l'option Acquire::https::Verify-Host et sa variante spécifique à l'hôte peuvent être
utilisées pour désactiver la fonction de sécurité. Le certificat fourni par le serveur comprend
l'identité du serveur qui devrait correspondre au nom de DNS utilisé pour y accéder. Par défaut, comme
cela est requis par la RFC 2818, le nom du miroir est vérifié par rapport à l'identité trouvée dans le
certificat. Ce comportement par défaut est sûr et ne devrait pas être modifié, mais si vous savez que le
serveur que vous utilisez à un nom de DNS qui ne correspond pas à l'identité de son certificat, il est
possible de régler l'option à "false", ce qui empêchera la réalisation de la comparaison.
Authentification du client
Outre la gestion de l'authentification basée sur les mots de passe (voir apt_auth.conf(5)) HTTPS prend
aussi en charge l'authentification basée sur les certificats du client avec Acquire::https::SSLCert et
Acquire::https::SSLKey. Leurs valeurs doivent être respectivement celle du nom de fichier du certificat
X.509 du client et celle de la clef privée (non chiffrée) associée, toutes les deux au format PEM. En
pratique, l'utilisation des variantes spécifiques à l'hôte des deux options est fortement recommandée.
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 à propos d'APT, veuillez lire
/usr/share/doc/debian/bug-reporting.txt ou utiliser la commande reportbug(1).
TRADUCTEURS
Jérôme Marant, Philippe Batailler, Christian Perrier <bubulle@debian.org> (2000, 2005, 2009, 2010), bubu
et Jean-Pierre Giraud <jean-pierregiraud@neuf.fr> (2004, 2017-2024) et l'équipe de traduction francophone
de Debian <debian-l10n-french@lists.debian.org>
Veuillez noter que cette traduction peut contenir des parties non traduites. Cela est volontaire, pour
éviter de perdre du contenu quand la traduction est légèrement en retard sur le contenu d'origine.
AUTEUR
Équipe de développement d'APT
NOTES
1. Page des bogues d'APT
https://bugs.debian.org/src:apt
APT 3.1.3 11 mai 2018 APT-TRANSPORT-HTTP(1)