On 11:49 Fri 22 May , Apollon Oikonomopoulos wrote:
> Unfortunately I didn't have the time to examine how Ganeti generates
> and
> distributes client.pem to the nodes. The fact that this bug is rarely seen and
> does not affect all clusters or nodes suggests that it is probably
> distribution-specific and has been fixed with issue #853. However, we have to
> make sure that:
>
> - Certificate generation works properly wrt. RFC 5280, i.e. generated
> certificates always have their Issuer encoded in the same way as the
> CA's Subject. If it doesn't, then the library used to sign the CSRs
> is at fault and the issue must be further investigated.
>
> - We never touch/re-encode the client certificates on distribution. I assume
> this has been fixed with #853.
After reading Ganeti's code a bit, it gets a little more complicated by
the fact that both server.pem and client.pem are self-signed. This means
two things:
- We implicitly rely on the fact that both certificates carry the same
subject to get the clients to send their certificates to noded. Remember
that the ServerHello message indicates "trusted" CAs by name and not by e.g.
fingerprint. If server.pem's subject ever changes to something different
than client.pem's, SSL will possibly break.
- OpenSSL is not to blame, because all it does is it creates a
self-signed certificate, with what happens to be the default DER encoding at
that point, which may be printableString or utf8String.
I also verified this behaviour on our own cluster, where we added 5 Jessie
nodes on a Wheezy cluster yesterday. All Jessie nodes have utf8String issuers
in their client.pem, the wheezy nodes all have printableStrings, indicating a
change in OpenSSL's defaults between 1.0.1 and 1.0.2. A quick way to see if a
cluster is affected by this is to run:
gnt-cluster command openssl x509 -noout -issuer \
-nameopt oneline,show_type \
-in /var/lib/ganeti/client.pem | grep ^issuer | sort | uniq -c
Also, reading through OpenSSL's changelog, I spotted the following in the
0.9.8 release cycle:
*) Perform some character comparisons of different types in X509_NAME_cmp:
this is needed for some certificates that reencode DNs into UTF8Strings
(in violation of RFC3280) and can't or wont issue name rollover
certificates.
[Steve Henson]
So, it seems that OpenSSL may indeed handle this case explicitly.
Cheers,
Apollon
