Using a self-signed SSL cert for an HTTPS-based internal APT repository

Question

I've set up a Debian repository (Ubuntu actually) for internal use with some private packages, and now want to make it available over the web to some specific servers. I would like apt-get / aptitude to connect to it using HTTPS, and because I don't want to spend any money am using a self-signed certificate.

I've tried following the apt.conf man page on pointing apt-get to use my own root CA certificate to validate the host, but it does not seem to work.

My apt.conf file looks like this:

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

I also use a client certificate, but it does not seem to be a problem because when I set Verify-Peer to "false" (commented above) everything works.

Using the same CA certificate, client cert and key works well with curl.

I enabled apt debugging (Debug::Acquire::https "true") but it offers very little information.

Any suggestions on how to proceed?

Solution 1

Hopefully this helps others - I have not been able to solve this directly.

As a workaround, I am now using stunnel4 to create a tunnel to my HTTPS repository. Self-signed certs and the client certificate I have work very well with stunnel4.

I've set up stunnel to listen on localhost:8888 for incoming connections, and direct them to my repo (repo.mydomain.com:443). I've set up apt to look for my repository at http://localhost:8888/.

So far this has been working well, although it seems like an unnecessary hack.

Solution 2

Recently, I have encountered a similar problem. I solved it by adding SslForceVersion option.

My config is like:

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

    CaInfo "/tmp/ca.crt";

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

Solution 3

I don't use client authentication, only HTTPS, but I only got it to work using this:

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

I put this into the file, /etc/apt/apt.conf.d/90sslverify.

Solution 4

I solved it in another way, by installing the ca-certificate.

1. Copy your *.crt file to /usr/local/share/ca-certificates/
2. run sudo update-ca-certificates

Works with Ubuntu 14.04.

Solution 5

In askubuntu, I found a somewhat simpler version of this solution and one that limited the option to a single host.

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

This worked for me.

The questioner here, however, wanted to preserve authentication; I tried a few things along the above lines, but couldn't make it work either. On the other hand, since my repository is signed and I have installed the signing key, the SSL authentication isn't critical for security.

View more solutions

Comments

[shevron]

again, not what I want - I do need peer verification. That said, personally I have a working setup (see my workaround with stunnel). This may still help others.

[Michael Hampton]

Be careful with this. Web sites are beginning to disable SSLv3 for various security reasons; in the future only TLSv1 and higher will work, and later only TLSv1.2+

[djmitche]

Actually, this is correct -- Apache supports SNI, and is alerting when the hostname it receives from the client doesn't match the configured hostname of the server. It'd be nice if apt would print the alert details, but it's doing the right thing. Falling back to SSLv3 is very unwise these days, and only "works" because you're disabling features you really should be using.

[Jordan]

This also works around proxies doing SSL interception/decryption. Simply adding the cert to /etc/ssl/certs does not. Thank you for this!

[Paul]

It does not work because certificate installed by me is a self-signed certificate from our firewall. I have no other certificate.