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?


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";
  • 2
    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.

  • 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

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.

  • 1
    This also works around proxies doing SSL interception/decryption. Simply adding the cert to /etc/ssl/certs does not. Thank you for this! – Jordan Anderson Jan 5 '17 at 14:24
  • It does not work because certificate installed by me is a self-signed certificate from our firewall. I have no other certificate. – Paul Feb 5 at 15:15

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.

  • 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

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.


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'

  • 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 clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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