Використання сертифікованої SSL-серти для внутрішнього сховища APT на базі HTTPS

Я створив сховище Debian (фактично Ubuntu) для внутрішнього використання з деякими приватними пакетами, і тепер хочу зробити його доступним через Інтернет на деяких конкретних серверах. Я хотів би apt-get / здатність підключитися до нього за допомогою HTTPS, і тому, що я не хочу витрачати гроші, використовуючи сертифікат, який підписав власноруч.

Я спробував перейти на сторінку man apt.conf на вказівку apt-get, щоб використовувати власний кореневий сертифікат CA для перевірки хоста, але, схоже, це не працює.

Мій файл apt.conf виглядає так:

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

Я також використовую клієнтський сертифікат, але це, здається, не є проблемою, оскільки коли я встановив Verify-Peer на "false" (коментується вище), все працює.

Використовуючи той самий сертифікат CA, клієнт cert і ключ добре працює з curl.

Я ввімкнув влучну налагодження (Debug :: Acquire :: https "true"), але вона пропонує дуже мало інформації.

Будь-які пропозиції щодо того, як діяти?

Я не використовую автентифікацію клієнта, лише HTTPS, але я працюю лише з цим:

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

Я помістив це у файл під /etc/apt/apt.conf.d.

Останнім часом я стикався з подібною проблемою. Я вирішив це, додавши SslForceVersionваріант.

Мій конфігурація виглядає так:

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

    CaInfo "/tmp/ca.crt";

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

У askubuntu я знайшов дещо простішу версію цього рішення і таку, яка обмежила можливість одним хостом.

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

Це працювало для мене.

Однак запитуючий тут хотів зберегти автентифікацію; Я спробував декілька речей, описаних вище, але і це не могло. З іншого боку, оскільки моє сховище підписане і я встановив ключ підпису, автентифікація SSL не є критичною для безпеки.

Я вирішив це іншим способом, встановивши ca-сертифікат.

1. Скопіюйте *.crtфайл у `/ usr / local / share / ca-сертифікати /
2. бігати sudo update-ca-certificates

Це рішення працює принаймні з Ubuntu 14.04.

Сподіваюся, це допомагає іншим - я не зміг вирішити це безпосередньо.

Як вирішення, я зараз використовую stunnel4 для створення тунелю до мого сховища HTTPS. Сертифікати з власним підписом та сертифікат клієнта я дуже добре працюю зі stunnel4.

Я налаштував оглушення для прослуховування в localhost: 8888 для вхідних з'єднань і скеровував їх до мого репо (repo.mydomain.com:243). Я налаштував вміння шукати своє сховище за адресою http: // localhost: 8888 / .

Поки що це працює добре, хоча це здається зайвим злом.

GnuTLS або apt, здається, баггі. Якщо ім'я хоста з мого apt source.list не відповідає Apache ServerName з мого веб-сервера сховища, я отримую таку помилку за допомогою TLSv1:

W: Не вдалося отримати https: //repo.example/debian/dists/unstable/non-free/binary-amd64/Packages : gnutls_handshake () не вдалося: надійшло попередження про TLS.

За допомогою SSLv3 все працює добре.

Примітка. Це не має нічого спільного з сертифікатом SSL. Недійсний сертифікат призведе до такої помилки:

Err https: //repo1.example нестабільне / невільні i386 пакети SSL: суб'єкт сертифіката ім'я (repo.example) не відповідає цільовому імені хоста «repo1.example»