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

Eu configurei um repositório Debian (Ubuntu, na verdade) para uso interno em alguns pacotes particulares 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, como não quero gastar dinheiro, estou usando um certificado autoassinado.

Tentei seguir a página de manual do apt.conf ao apontar o apt-get para usar meu próprio certificado de CA raiz para validar o host, mas parece não funcionar.

Meu arquivo apt.conf fica assim:

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

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

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

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

Alguma sugestão de como proceder?

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

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

Coloquei isso em um arquivo abaixo /etc/apt/apt.conf.d.

Recentemente, encontrei um problema semelhante. Eu resolvi adicionando SslForceVersionopção.

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

No askubuntu , encontrei uma versão um pouco mais simples dessa 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; Tentei algumas coisas ao longo das linhas acima, mas também não consegui fazê-lo funcionar. Por outro lado, como meu repositório está assinado e eu instalei a chave de assinatura, a autenticação SSL não é essencial para a segurança.

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

1. Copie seu *.crtarquivo para `/ usr / local / share / ca-certificates /
2. corre sudo update-ca-certificates

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

Espero que isso ajude outras pessoas - não fui capaz de resolver isso diretamente.

Como solução alternativa, agora estou usando o stunnel4 para criar um encapsulamento para meu repositório HTTPS. Certificados autoassinados e certificado de cliente. Trabalho muito bem com stunnel4.

Configurei o stunnel para escutar no localhost: 8888 as conexões recebidas e encaminhei-as ao meu repo (repo.mydomain.com:443). Eu configurei o apt para procurar meu repositório em http: // localhost: 8888 / .

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

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

W: Falha ao buscar https: //repo.example/debian/dists/unstable/non-free/binary-amd64/Packages : gnutls_handshake () falhou: um alerta de aviso TLS foi recebido.

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 instável / não livre de pacotes i386 SSL: o nome do assunto do certificado (repo.example) não corresponde ao nome do host de destino 'repo1.example'