3

I ported the same working SSL client key/certificate and /etc/apt/apt.conf.d/01_https_client_cert rule from an (working) 14.04 VM to a fresh 16.04 installation.

I am able to use the SSL client certificate to access the apt repo via curl but apt-get update complains with this error:

6% [Working]* Hostname example.com was found in DNS cache
*   Trying 11.22.33.44...
* Connected to example.com (11.22.33.44) port 443 (#29)
* found 173 certificates in /etc/ssl/certs/ca-certificates.crt
* found 697 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* error reading X.509 key or certificate file: Error while reading file.
* Closing connection 29
Ign:5 https://example.com/apt release/main all Packages

/etc/apt/apt.conf.d/01_ssl_client_auth is the same on both systems:

Debug::Acquire::https "true";
Acquire::https::example.com::SslCert "/opt/example/keyring/ssl_client.crt";
Acquire::https::example.com::SslKey "/opt/example/keyring/ssl_client.key";

Permissions are the same on both machines:

ubuntu@ubuntu:~$ namei -mo /opt/example/keyring/ssl_client.crt
f: /opt/example/keyring/ssl_client.crt
 drwxr-xr-x root    root    /
 drwxr-sr-x ubuntu ubuntu opt
 drwxrwsr-x ubuntu ubuntu example
 drwxrws--- ubuntu ubuntu keyring
 -rw-rw---- ubuntu ubuntu ssl_client.crt

Trivia:

  1. Removing the 01_ssl_client_auth rule returns the expected 403 forbidden response (as repo requires client certificate)

  2. curl works just fine like so:

    curl --cert /opt/example/keyring/ssl_client.crt --key /opt/example/keyring/ssl_client.key https://example.com/apt/
    
    Connected to example.com (11.22.33.44) port 443 (#0)
    found 173 certificates in /etc/ssl/certs/ca-certificates.crt
    found 697 certificates in /etc/ssl/certs
    ALPN, offering http/1.1
    SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
         server certificate verification OK
         server certificate status verification SKIPPED
         common name: *.example.com (matched)
         server certificate expiration date OK
         server certificate activation date OK
         certificate public key: RSA
           (snip)
    ALPN, server did not agree to a protocol
    GET /apt/ HTTP/1.1
    Host: example.com
    User-Agent: curl/7.47.0
    Accept: */*
    
    HTTP/1.1 200 OK
    Server: nginx/1.4.6 (Ubuntu)
    Date: Wed, 18 May 2016 01:18:30 GMT
    Content-Type: text/html
    Transfer-Encoding: chunked
    Connection: keep-alive
    
  3. And of course apt-get and curl both work on the original system with same apt.conf.d and cert...


Anything else I should look at? Was there some change from crt/key to pem in apt-get or something?

1
  • OK... So I have it working by setting +rw for the OTHER permission. But this is still different than behavior for apt-get in 14.04 so I am curious for explanation. Does apt run as separate user now than root? E.g. chmod 666 /opt/example/keyring and chmod 666 /opt/example/keyring/ssl_client.*. Thanks! (And yeah simply +r probably would suffice.) May 18, 2016 at 2:01

2 Answers 2

2

You should be able find more details from https://wiki.ubuntu.com/XenialXerus/ReleaseNotes#Apt_1.2

Recommend settings is copy the cert and keys to a different directory and change the user permissions to

_apt:nogroup

and configure

apt_transport_https

setup to use the new path.

Acquire::https::cdn-mirror.insnw.net::CaInfo "/new/path/ca.crt";
Acquire::https::cdn-mirror.insnw.net::SslCert "/new/path.crt";
Acquire::https::cdn-mirror.insnw.net::SslKey  "/new/path.key"";
1

Apt tries hard to drop permissions and run as the _apt user. I don't remember when that switch happened but it was fairly recent (i.e. likely to be after 14.04). So, having fixed my similar problem the same way you did (i.e. made sure that a+rx was available on all directories leading up to the cert I wanted _apt to use) I think it's safe to say you've identified the problem correctly.

1

You must log in to answer this question.

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