Usando um certificado SSL autoassinado para um repositório APT interno baseado em HTTPS

Question

Eu configurei um repositório Debian (Ubuntu na verdade) para uso interno com alguns pacotes privados, e agora quero disponibilizá-lo pela web para alguns servidores específicos. Eu gostaria que o apt-get / aptitude se conectasse a ele usando HTTPS, e porque eu não quero gastar dinheiro estou usando um certificado auto-assinado.

Eu tentei seguir a página man do apt.conf ao apontar para o apt-get para usar meu próprio certificado de CA raiz para validar o host, mas parece que não funciona.

Meu arquivo apt.conf tem esta aparência:

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

Eu também uso um certificado de cliente, mas isso não parece ser um problema, porque quando eu configurei o Verify-Peer para "false" (comentado acima) tudo funciona.

Usando o mesmo certificado de CA, o certificado de cliente e a chave funcionam bem com o curl.

Eu habilitei a depuração do apt (Debug :: Acquire :: https "true"), mas ela oferece muito pouca informação.

Alguma sugestão sobre como proceder?

    

Answer 1

Espero que isso ajude os outros - não consegui resolver isso diretamente.

Como solução alternativa, estou usando o stunnel4 para criar um túnel para o meu repositório HTTPS. Certificados auto-assinados e o certificado do cliente Tenho muito trabalho com o stunnel4.

Eu configurei o stunnel para escutar localhost: 8888 para conexões de entrada e direcioná-las ao meu repo (repo.mydomain.com:443). Eu configurei o apt para procurar meu repositório no link .

Até agora isso tem funcionado bem, embora pareça um hack desnecessário.

    

Answer 2

Recentemente, encontrei um problema semelhante. Eu resolvi adicionando a opção SslForceVersion .

Minha configuração é como:

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

    CaInfo "/tmp/ca.crt";

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

    

Answer 3

Eu não uso autenticação de cliente, apenas HTTPS, mas só consegui trabalhar com isso:

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

Eu coloquei isso em um arquivo em /etc/apt/apt.conf.d .

    

Answer 4

Em askubuntu , encontrei uma versão mais simples desta solução e uma que limitava a opção a um único host.

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

Isso funcionou para mim.

O questionador aqui, no entanto, queria preservar a autenticação; Eu tentei algumas coisas ao longo das linhas acima, mas também não consegui fazer funcionar. Por outro lado, como meu repositório está assinado e eu instalei a chave de assinatura, a autenticação SSL não é crítica para a segurança.

    

Answer 5

Eu resolvi de outra maneira, instalando o certificado de certificado.

1. Copie o arquivo *.crt para '/ usr / local / share / ca-certificates /
2. executar sudo update-ca-certificates

Esta solução funciona com o Ubuntu 14.04 pelo menos.

    

Answer 6

O GnuTLS ou o apt parecem estar com bugs. Se o nome do host do meu apt sources.list não corresponder ao Apache ServerName do meu servidor do repositório, recebo o seguinte erro usando o TLSv1:

W: Failed to fetch https://repo.example/debian/dists/unstable/non-free/binary-amd64/Packages: gnutls_handshake() failed: A TLS warning alert has been received.

Usando o SSLv3, tudo funciona bem.

Nota: isso não tem nada a ver com o certificado SSL. Um certificado inválido resultaria no seguinte erro:

Err https://repo1.example unstable/non-free i386 Packages SSL: certificate subject name (repo.example) does not match target host name 'repo1.example'