Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question

5 Answers 5

up vote 1 down vote accepted

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.

share|improve this answer

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.

share|improve this answer
    
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. –  shevron Jul 9 '13 at 6:00

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";
};
share|improve this answer
1  
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+ –  Michael Hampton Dec 13 '13 at 7:57

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 on a file under /etc/apt/apt.conf.d.

share|improve this answer
1  
That's exactly what I don't want - I do want to verify the server using my own CA Cert. Disabling verification works but I don't want to do it long term. –  shevron Dec 14 '11 at 15:24

GnuTLS or apt seems to be buggy. If the host name from my apt sources.list does not match the Apache ServerName from my repository webserver I get the following error using 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.

Using SSLv3 everything works fine.

Note: This has nothing to do with the SSL certificate. An invalid certificate would result in the following error:

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

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.