Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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: "false";      "/etc/apt/certs/my-cacert.pem";     "/etc/apt/certs/my-cert.pem";      "/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

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

My config is like: {
    Verify-Peer "true";
    Verify-Host "true";

    CaInfo "/tmp/ca.crt";

    SslCert "/tmp/client.crt";
    SslKey  "/tmp/client.key";
    SslForceVersion "SSLv3";
share|improve this answer
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
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

In askubuntu, I found a somewhat simpler version of this solution and one that limited the option to a single host. "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
up vote 0 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 ( 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

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

This solution works with Ubuntu 14.04 at least.

share|improve this answer

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
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. – djmitche Jan 27 '15 at 13:52

Your Answer


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.