Utilisation d'un certificat SSL auto-signé pour un référentiel APT interne basé sur HTTPS

10

J'ai mis en place un référentiel Debian (Ubuntu en fait) à usage interne avec certains paquets privés, et je veux maintenant le rendre disponible sur le Web à certains serveurs spécifiques. Je voudrais qu'apt-get / aptitude s'y connecte en utilisant HTTPS, et parce que je ne veux pas dépenser d'argent, j'utilise un certificat auto-signé.

J'ai essayé de suivre la page de manuel apt.conf sur le pointage apt-get pour utiliser mon propre certificat d'autorité de certification racine pour valider l'hôte, mais cela ne semble pas fonctionner.

Mon fichier apt.conf ressemble à ceci:

#Acquire::https::repo.mydomain.com::Verify-Peer "false";
Acquire::https::repo.mydomain.com::CaInfo      "/etc/apt/certs/my-cacert.pem";
Acquire::https::repo.mydomain.com::SslCert     "/etc/apt/certs/my-cert.pem";
Acquire::https::repo.mydomain.com::SslKey      "/etc/apt/certs/my-key.pem";

J'utilise également un certificat client, mais cela ne semble pas être un problème car lorsque je mets Verify-Peer sur "false" (commenté ci-dessus), tout fonctionne.

L'utilisation du même certificat CA, du même certificat client et de la même clé fonctionne bien avec curl.

J'ai activé le débogage apt (Debug :: Acquire :: https "true") mais il offre très peu d'informations.

Des suggestions sur la façon de procéder?

Shevron
la source

Réponses:

5

Je n'utilise pas l'authentification client, seulement HTTPS, mais je l'ai seulement fait fonctionner en utilisant ceci:

Acquire::https {
        Verify-Peer "false";
        Verify-Host "false";
}

Je mets cela sur un fichier sous /etc/apt/apt.conf.d.

coredump
la source
1
C'est exactement ce que je ne veux pas - je veux vérifier le serveur en utilisant mon propre CA Cert. La désactivation de la vérification fonctionne mais je ne veux pas le faire à long terme.
shevron
5

Récemment, j'ai rencontré un problème similaire. Je l'ai résolu en ajoutant une SslForceVersionoption.

Ma configuration est comme:

Acquire::https::test.com {
    Verify-Peer "true";
    Verify-Host "true";

    CaInfo "/tmp/ca.crt";

    SslCert "/tmp/client.crt";
    SslKey  "/tmp/client.key";
    SslForceVersion "SSLv3";
};
Une bouche
la source
2
Soyez prudent avec cela. Les sites Web commencent à désactiver SSLv3 pour diverses raisons de sécurité; à l'avenir, seul TLSv1 et supérieur fonctionnera, et plus tard uniquement TLSv1.2 +
Michael Hampton
3

Dans askubuntu , j'ai trouvé une version un peu plus simple de cette solution et une qui limitait l'option à un seul hôte.

Acquire::https::mirror.ufs.ac.za::Verify-Peer "false";

Cela a fonctionné pour moi.

Le questionneur ici, cependant, voulait préserver l'authentification; J'ai essayé quelques choses dans le sens ci-dessus, mais je n'ai pas pu le faire fonctionner non plus. En revanche, étant donné que mon référentiel est signé et que j'ai installé la clé de signature, l'authentification SSL n'est pas critique pour la sécurité.

Ted
la source
encore une fois, pas ce que je veux - je fais la vérification nécessaire par les pairs. Cela dit, personnellement, j'ai une configuration de travail (voir ma solution de contournement avec Stunnel). Cela peut encore aider les autres.
shevron
3

Je l'ai résolu d'une autre manière, en installant le ca-certificate.

  1. Copiez votre *.crtfichier dans `/ usr / local / share / ca-certificats /
  2. courir sudo update-ca-certificates

Cette solution fonctionne avec Ubuntu 14.04 au moins.

ortang
la source
1
Cela fonctionne également autour de procurations effectuant l'interception / décryptage SSL. Le simple fait d'ajouter le certificat à / etc / ssl / certs ne le fait pas. Merci pour ça!
Jordan Anderson
1
Cela ne fonctionne pas car le certificat que j'ai installé est un certificat auto-signé de notre pare-feu. Je n'ai pas d'autre certificat.
Paul
1

J'espère que cela aide les autres - je n'ai pas pu résoudre cela directement.

Pour contourner ce problème, j'utilise maintenant stunnel4 pour créer un tunnel vers mon référentiel HTTPS. Les certificats auto-signés et le certificat client que je travaille très bien avec stunnel4.

J'ai configuré Stunnel pour écouter sur localhost: 8888 les connexions entrantes et les diriger vers mon référentiel (repo.mydomain.com:443). J'ai configuré apt pour rechercher mon référentiel sur http: // localhost: 8888 / .

Jusqu'à présent, cela a bien fonctionné, même si cela semble être un hack inutile.

Shevron
la source
-1

GnuTLS ou apt semble être bogué. Si le nom d'hôte de mon apt sources.list ne correspond pas à Apache ServerName de mon serveur Web de référentiel, j'obtiens l'erreur suivante en utilisant TLSv1:

W: Impossible de récupérer https: //repo.example/debian/dists/unstable/non-free/binary-amd64/Packages : gnutls_handshake () a échoué: une alerte d'avertissement TLS a été reçue.

En utilisant SSLv3, tout fonctionne bien.

Remarque: cela n'a rien à voir avec le certificat SSL. Un certificat non valide entraînerait l'erreur suivante:

Err https: //repo1.example packages i386 instables / non libres SSL: le nom du sujet du certificat (repo.example) ne correspond pas au nom d'hôte cible 'repo1.example'

Jörg Ludwig
la source
En fait, c'est correct - Apache prend en charge SNI et alerte lorsque le nom d'hôte qu'il reçoit du client ne correspond pas au nom d'hôte configuré du serveur. Ce serait bien si apt imprimait les détails de l'alerte, mais cela fait la bonne chose. Revenir à SSLv3 est très imprudent de nos jours, et ne "fonctionne" que parce que vous désactivez les fonctionnalités que vous devriez vraiment utiliser.
djmitche