<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/4.4.4">
</HEAD>
<BODY>
Am Sonntag, den 22.06.2014, 08:22 +0200 schrieb Andreas Metzler:
<BLOCKQUOTE TYPE=CITE>
<PRE>
On 2014-06-22 Jo Drexl <<A HREF="mailto:jo.drexl@poly-tick.de">jo.drexl@poly-tick.de</A>> 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
</PRE>
</BLOCKQUOTE>
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:<BR>
<BR>
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.<BR>
serverkey.pem is created afterwards and signed with cacert.pem, cakey.pem and server.info as template, yielding servercert.pem. <BR>
<BR>
At this step the certificate chain should be a piece of cake (if I didn't get something totally wrong, which I doubt):<BR>
servercert.pem --[verified against]--> cacert.pem [CA, self-signed] [CHAIN END]<BR>
<BR>
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. <BR>
<BR>
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. <BR>
<BR>
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>
<BR>
BR<BR>
Jo
</BODY>
</HTML>