Uso de un certificado SSL autofirmado para un repositorio APT interno basado en HTTPS

He configurado un repositorio de Debian (Ubuntu en realidad) para uso interno con algunos paquetes privados, y ahora quiero que esté disponible en la web para algunos servidores específicos. Me gustaría que apt-get / aptitude se conecte a él usando HTTPS, y porque no quiero gastar dinero estoy usando un certificado autofirmado.

Intenté seguir la página de manual de apt.conf al apuntar apt-get para usar mi propio certificado de CA raíz para validar el host, pero no parece funcionar.

Mi archivo apt.conf se ve así:

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

También uso un certificado de cliente, pero no parece ser un problema porque cuando configuro Verify-Peer en "falso" (comentado anteriormente) todo funciona.

Al usar el mismo certificado de CA, el certificado y la clave del cliente funcionan bien con curl.

He habilitado la depuración de apt (Debug :: Acquire :: https "true") pero ofrece muy poca información.

¿Alguna sugerencia sobre cómo proceder?

No uso la autenticación del cliente, solo HTTPS, pero solo lo hice funcionar usando esto:

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

Puse esto en un archivo debajo /etc/apt/apt.conf.d.

Recientemente, me he encontrado con un problema similar. Lo resolví agregando la SslForceVersionopción.

Mi configuración es 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";
};

En askubuntu , encontré una versión algo más simple de esta solución y una que limitaba la opción a un solo host.

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

Esto funcionó para mí.

El interlocutor aquí, sin embargo, quería preservar la autenticación; Intenté algunas cosas a lo largo de las líneas anteriores, pero tampoco pude hacerlo funcionar. Por otro lado, dado que mi repositorio está firmado y he instalado la clave de firma, la autenticación SSL no es crítica para la seguridad.

Lo resolví de otra manera, instalando el certificado ca.

1. Copie su *.crtarchivo a `/ usr / local / share / ca-certificados /
2. correr sudo update-ca-certificates

Esta solución funciona con Ubuntu 14.04 al menos.

Espero que esto ayude a otros, no he podido resolver esto directamente.

Como solución alternativa, ahora estoy usando stunnel4 para crear un túnel a mi repositorio HTTPS. Los certificados autofirmados y el certificado del cliente que tengo funcionan muy bien con stunnel4.

He configurado stunnel para escuchar en localhost: 8888 las conexiones entrantes y dirigirlas a mi repositorio (repo.mydomain.com:443). He configurado apt para buscar mi repositorio en http: // localhost: 8888 / .

Hasta ahora, esto ha estado funcionando bien, aunque parece un truco innecesario.

GnuTLS o apt parece tener errores. Si el nombre de host de mi apt sources.list no coincide con el nombre de servidor Apache de mi servidor web de repositorio, aparece el siguiente error usando TLSv1:

W: no se pudo obtener https: //repo.example/debian/dists/unstable/non-free/binary-amd64/Packages : gnutls_handshake () falló: se recibió una alerta de advertencia de TLS.

Usando SSLv3 todo funciona bien.

Nota: Esto no tiene nada que ver con el certificado SSL. Un certificado no válido generaría el siguiente error:

Err https: //repo1.example Paquetes i386 inestables / no libres SSL: el nombre del sujeto del certificado (repo.example) no coincide con el nombre de host de destino 'repo1.example'