Bug#752272: Last certificate not self-signed

[Jo Drexl]

Am Sonntag, den 22.06.2014, 08:22 +0200 schrieb Andreas Metzler:

> On 2014-06-22 Jo Drexl <jo.drexl at poly-tick.de> wrote:
> > After installing the stable package and rerunning 'certtool -e
> > --load-ca-certificate cacert.pem --infile servercert.pem', the outcome
> > was:
> [...]
> > It seems the self-sign for snakeoil CAs is broken.
> > Good luck, I don't think I'm of much use here, still playing around and
> > trying to find out what I'm doing here ;)
> 
> Hell,
> 
> You are trying to use -e but you are passing a single certificate
> instead of a certificate chain.
> 
> |  -e, --verify-chain
> |         Verify a PEM encoded certificate chain.
> |
> |         The last certificate in the chain must be a self signed one.
> 
> If you used --verify instead the command would succeed.
> 
> cu Andreas

Sure I do only give him one ca-certificate - because it's the next and
last one in the chain and is self-signed (certtool
--generate-self-signed --load-privkey cakey.pem --template ca.info
--outfile cacert.pem). I did follow the howto step by step. To clarify:

cakey.pem is created (RSA 2432 bits), self signed with ca.info as
template and thus yields cacert.pem as the certificate authority's
public certificate to sign and verify all other keys with.
serverkey.pem is created afterwards and signed with cacert.pem,
cakey.pem and server.info as template, yielding servercert.pem. 

At this step the certificate chain should be a piece of cake (if I
didn't get something totally wrong, which I doubt):
servercert.pem --[verified against]--> cacert.pem [CA, self-signed]
[CHAIN END]

servercert.pem is verified by cacert.pem, which is self-signed and a
trusted certificate authority. Nothing above it. So either the
cacert.pem is not self-signed and therefore not trusted (which would be
awkward and a bug all by itself, which I'd gladly file too), or - as the
message indicates - servercert.pem can't be verified by cacert.pem,
which either indicates a failure within the verification routine or
within the signature routine. And even if this parameter doesn't work
with my setup, libvirt should accept the keys. Well, it doesn't, telling
me my own client certificate (which I generated the same way as the
servercert.pem, with own key and own template) can't be verified by the
certificate authority's cert. 

Of course I could have fucked up stuff, but I don't think so. I'm
neither stupid nor did I just do this once. I tried it multiple times
(with either rsa or ecc keys) on the server, and once (after being sure
it's not me) verified the issue with my notebook. I've redone this chain
at least 6 times, the last two by EXACTLY following the above mentioned
tutorial (I didn't even change the proposed lines in the templates) on
two different machines with both Debian Wheezy and the backports-package
installed. With the stable package it works now again, and I changed
quite a lot within the templates. 

All summed up: It worked with the stable package for the VM setup I'm
working on, it didn't work multiple times with the testing-package and
now it works again with the stable package. It's the package. Quod erat
demonstrandum.

BR
Jo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnutls-maint/attachments/20140622/54fdf145/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnutls-maint/attachments/20140622/54fdf145/attachment.sig>