Назад | Перейти на главную страницу

Использование самоподписанного сертификата SSL для внутреннего репозитория APT на основе HTTPS

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

Я пробовал следовать справочной странице 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, клиентский сертификат и ключ хорошо работают с curl.

Я включил подходящую отладку (Debug :: Acquire :: https "true"), но она предлагает очень мало информации.

Есть предложения о том, как действовать?

Недавно столкнулся с подобной проблемой. Я решил это, добавив 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";
};

Я не использую аутентификацию клиента, только HTTPS, но я заставил ее работать только с помощью этого:

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

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

Решил по-другому, установив ca-сертификат.

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

Это решение работает как минимум с Ubuntu 14.04.

В Аскубунту, Я нашел несколько более простую версию этого решения, которая ограничивала выбор одним хостом.

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

Это сработало для меня.

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

Надеюсь, это поможет другим - я не смог решить эту проблему напрямую.

В качестве обходного пути я теперь использую stunnel4 для создания туннеля к моему репозиторию HTTPS. Самоподписанные сертификаты и сертификат клиента, который у меня есть, очень хорошо работают с stunnel4.

Я настроил stunnel для прослушивания входящих подключений на localhost: 8888 и направления их на мое репо (repo.mydomain.com:443). Я настроил поиск своего репозитория на http: // локальный: 8888 /.

До сих пор это работало хорошо, хотя это кажется ненужным взломом.

Кажется, что в GnuTLS или apt есть ошибки. Если имя хоста из моего apt sources.list не совпадает с Apache ServerName из моего веб-сервера репозитория, я получаю следующую ошибку, используя TLSv1:

W: не удалось получить https: //repo.example/debian/dists/unstable/non-free/binary-amd64/Packages: gnutls_handshake () failed: получено предупреждение TLS.

При использовании SSLv3 все работает нормально.

Примечание. Это не имеет ничего общего с сертификатом SSL. Недействительный сертификат приведет к следующей ошибке:

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