Używanie samopodpisanego certyfikatu SSL dla wewnętrznego repozytorium APT opartego na HTTPS

Założyłem repozytorium Debiana (właściwie Ubuntu) do użytku wewnętrznego z niektórymi pakietami prywatnymi, a teraz chcę udostępnić je przez Internet niektórym określonym serwerom. Chciałbym, aby apt-get / aptitude łączył się z nim za pomocą HTTPS, a ponieważ nie chcę wydawać żadnych pieniędzy, korzystam z certyfikatu z podpisem własnym.

Próbowałem śledzić stronę podręcznika apt.conf dotyczącą wskazania apt-get, aby użyć własnego certyfikatu głównego urzędu certyfikacji do sprawdzenia poprawności hosta, ale wydaje się, że to nie działa.

Mój plik apt.conf wygląda następująco:

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

Korzystam również z certyfikatu klienta, ale nie wydaje się to być problemem, ponieważ kiedy ustawię Verify-Peer na „false” (skomentowano powyżej) wszystko działa.

Korzystanie z tego samego certyfikatu CA, certyfikatu klienta i klucza działa dobrze z curl.

Włączyłem apt debugowanie (Debug :: Acquire :: https „true”), ale oferuje bardzo mało informacji.

Wszelkie sugestie dotyczące dalszego postępowania?

Nie używam uwierzytelniania klienta, tylko HTTPS, ale mam go tylko do pracy przy użyciu tego:

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

Umieściłem to w pliku pod /etc/apt/apt.conf.d.

Ostatnio spotkałem podobny problem. Rozwiązałem to, dodając SslForceVersionopcję.

Moja konfiguracja to:

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

    CaInfo "/tmp/ca.crt";

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

W askubuntu znalazłem nieco prostszą wersję tego rozwiązania i taką, która ograniczyła opcję do jednego hosta.

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

To zadziałało dla mnie.

Pytający tutaj chciał jednak zachować uwierzytelnienie; Próbowałem kilku rzeczy zgodnie z powyższymi wskazówkami, ale nie mogłem też sprawić, by działało. Z drugiej strony, ponieważ moje repozytorium jest podpisane i zainstalowałem klucz do podpisywania, uwierzytelnianie SSL nie ma decydującego znaczenia dla bezpieczeństwa.

Rozwiązałem to w inny sposób, instalując certyfikat ca.

1. Skopiuj *.crtplik do `/ usr / local / share / ca-certyfikaty /
2. biegać sudo update-ca-certificates

To rozwiązanie działa przynajmniej z Ubuntu 14.04.

Mam nadzieję, że to pomaga innym - nie byłem w stanie rozwiązać tego bezpośrednio.

Aby obejść ten problem, używam teraz stunnel4 do utworzenia tunelu do mojego repozytorium HTTPS. Certyfikaty z podpisem własnym i certyfikat klienta Mam bardzo dobrą pracę z stunnel4.

Skonfigurowałem stunnel, aby nasłuchiwał na localhost: 8888 dla połączeń przychodzących i kierował je do mojego repozytorium (repo.mydomain.com:443). Skonfigurowałem apt, aby szukał mojego repozytorium pod adresem http: // localhost: 8888 / .

Do tej pory działało to dobrze, choć wydaje się, że to niepotrzebne włamanie.

GnuTLS lub apt wydaje się być wadliwy. Jeśli nazwa hosta z mojego apt sources.list nie zgadza się z Apache ServerName z mojego serwera repozytorium, otrzymuję następujący błąd przy użyciu TLSv1:

W: Nie udało się pobrać https: //repo.example/debian/dists/unstable/non-free/binary-amd64/Packages : gnutls_handshake () nie powiodło się: Otrzymano ostrzeżenie TLS.

Używając SSLv3 wszystko działa dobrze.

Uwaga: nie ma to nic wspólnego z certyfikatem SSL. Niepoprawny certyfikat spowoduje następujący błąd:

Err https: //repo1.example niestabilne / niewolne pakiety i386 SSL: nazwa podmiotu certyfikatu (repo.example) nie zgadza się z nazwą docelowego hosta „repo1.example”