apt-transport-https not sending client certificate
Mel Collins
I'm having a frustrating time trying to get apt to connect to a
(local) server using SSL client certificate authentication.
My apt config file looks like this:
Acquire {
https {
localhost {
Verify-Peer "true";
Verify-Host "true";
CaInfo "/tmp/certs/ca/ca.crt";
SslCert "/tmp/certs/client.crt";
SslKey "/tmp/certs/client.key";
};
};
};
(the server uses a certificate from a self-signed CA, hence the CaInfo)
The sources.list line is:
deb https://localhost:8443/deb test foo bar
Yet when I try an `aptitude update`, the server complains that no
client certificate was supplied ("SSL3_GET_CLIENT_CERTIFICATE:peer did
not return a certificate"). Thence, with the debug option turned on,
aptitude says:
* gnutls_handshake() failed: Error in the push function.
I've checked using Wireshark and, indeed, the client doesn't supply
any certificate during the SSL handshake ("Handshake protocol:
Certificate | Certificates length: 0").
I can run:
$ curl --insecure --cert "certs/client.crt" --key "certs/client.key"
--include "https://localhost:8443/"
or
$ gnutls-cli -V --insecure -p 8443 --x509certfile certs/client.crt
--x509keyfile certs/client.key 127.0.0.1
and in both cases the same client certificate gets sent, and accepted
by the server.
I've been working mostly with Ubuntu 10.04 (apt 0.7.25.3ubuntu9.5),
but the behaviour is the same using the latest apt in testing (as of
yesterday; 0.8.14.1).
I guess I must be doing something wrong/unusual, but I've run out of
ideas for things to try.
The only thing I can think of, given that both curl and gnutls-cli
work, is that some parameter is passed/defaulted by the https
transport which checks something my certs don't pass, so it silently
ignores them. But I looked through https.cc, and couldn't see anything
obvious (not that I know C very well), and silently ignoring a cert
seems too wonky to be likely.
Does anyone have any ideas?
Takk,
- Mel
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/BANLkTiksS_rSmN7D...@mail.gmail.com
Andrei POPESCU
> Hi all,
> I'm having a frustrating time trying to get apt to connect to a
> (local) server using SSL client certificate authentication.
Just out of curiosity, but why are you doing this?
Regards,
Andrei
--
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
Mel Collins
that I originally replied directly to Andrei, and I don't want people
to think I blanked him. :)
(Here's hoping I don't noob this one up, as well)
On 28 June 2011 21:00, Andrei POPESCU <andreim...@gmail.com> wrote:
> On Ma, 28 iun 11, 15:51:43, Mel Collins wrote:
>> On 28 June 2011 12:19, Andrei POPESCU <andreim...@gmail.com> wrote:
>> > Just out of curiosity, but why are you doing this?
>>
>> So I can create a secure repository with limited access (local
>> because it's currently only proof-of-concept, or lack thereof!), using
>> a method more secure than just sticking a username and password in the
>> apt URL. My understanding is that the sources.list file must be
>> world-readable, so isn't a very good place to keep secrets. :)
>> I've read a few posts here and there about people implementing
>> something similar, but if you have any better solutions I'm all ears
>> to that, too. :)
>
> "limited access" makes sense of course. I was asking merely because some
> people don't realise that secure-apt works even if the debs come from a
> completely untrustworthy source and/or are transmitted over insecure
> connections ;)
>
> Sorry to waste your time without even being able to help.
>
> Regards,
> Andrei
> P.S. If your message was meant for the list (instead of private mail)
> feel free to include my reply
>_>
- Mel
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/BANLkTikxaW9_f6Dy...@mail.gmail.com