Utilizzo di un certificato SSL autofirmato per un repository APT interno basato su HTTPS

Ho creato un repository Debian (Ubuntu in realtà) per uso interno con alcuni pacchetti privati, e ora voglio renderlo disponibile sul web ad alcuni server specifici. Vorrei che apt-get / aptitude si connettesse ad esso tramite HTTPS, e poiché non voglio spendere soldi sto usando un certificato autofirmato.

Ho provato a seguire la pagina man apt.conf puntando apt-get per usare il mio certificato CA root per convalidare l'host, ma sembra non funzionare.

Il mio file apt.conf è simile al seguente:

#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";

Uso anche un certificato client, ma non sembra essere un problema perché quando imposto Verify-Peer su "false" (commentato sopra) tutto funziona.

Utilizzando lo stesso certificato CA, il certificato client e la chiave funzionano bene con l'arricciatura.

Ho abilitato il debug di apt (Debug :: Acquire :: https "true") ma offre pochissime informazioni.

Qualche suggerimento su come procedere?

Non utilizzo l'autenticazione client, ma solo HTTPS, ma l'ho solo fatto funzionare usando questo:

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

Ho messo questo su un file sotto /etc/apt/apt.conf.d.

Di recente ho riscontrato un problema simile. L'ho risolto aggiungendo l' SslForceVersionopzione.

La mia configurazione è come:

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

    CaInfo "/tmp/ca.crt";

    SslCert "/tmp/client.crt";
    SslKey  "/tmp/client.key";
    SslForceVersion "SSLv3";
};

In askubuntu , ho trovato una versione un po 'più semplice di questa soluzione e una che limitava l'opzione a un singolo host.

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

Questo ha funzionato per me.

L'interrogante qui, tuttavia, voleva preservare l'autenticazione; Ho provato alcune cose seguendo le linee sopra, ma non sono riuscito a farlo funzionare. D'altra parte, poiché il mio repository è firmato e ho installato la chiave di firma, l'autenticazione SSL non è fondamentale per la sicurezza.

L'ho risolto in un altro modo, installando il certificato ca.

1. Copia il tuo *.crtfile in `/ usr / local / share / ca-certificati /
2. correre sudo update-ca-certificates

Questa soluzione funziona almeno con Ubuntu 14.04.

Spero che questo aiuti gli altri - non sono stato in grado di risolverlo direttamente.

Per ovviare a questo problema, ora sto usando stunnel4 per creare un tunnel per il mio repository HTTPS. Certi autofirmati e certificato del cliente ho lavorato molto bene con stunnel4.

Ho impostato Stunnel per l'ascolto su localhost: 8888 per le connessioni in entrata e le ho indirizzate al mio repository (repo.mydomain.com:443). Ho impostato apt per cercare il mio repository su http: // localhost: 8888 / .

Finora questo ha funzionato bene, anche se sembra un trucco inutile.

GnuTLS o apt sembrano essere difettosi. Se il nome host dal mio apt sources.list non corrisponde a Apache ServerName dal mio server web repository, ottengo il seguente errore utilizzando TLSv1:

W: Impossibile recuperare https: //repo.example/debian/dists/unstable/non-free/binary-amd64/Packages : gnutls_handshake () non riuscito: è stato ricevuto un avviso TLS.

Usando SSLv3 tutto funziona bene.

Nota: questo non ha nulla a che fare con il certificato SSL. Un certificato non valido comporterebbe il seguente errore:

Err https: //repo1.example pacchetti i386 instabili / non liberi SSL: il nome soggetto certificato (repo.example) non corrisponde al nome host di destinazione 'repo1.example'