14

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?

6 Answers 6

8

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.

1
  • 5
    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, 2011 at 15:24
7

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";
};
1
  • 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+ Dec 13, 2013 at 7:57
6

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.

3
  • 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
    Jan 5, 2017 at 14:24
  • 1
    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, 2019 at 15:15
  • 1
    It also will not work if you need the certificates to install update-ca-certificates in the first place.
    – Joerg S
    Aug 1, 2022 at 8:32
4

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.

1
  • 1
    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, 2013 at 6:00
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.

-1

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'

1
  • 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, 2015 at 13:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .