Comment #2 on issue 1173 by bcandler...@googlemail.com: gnt-instance move >
socat: E certificate is valid but its commonName does not match hostname
https://code.google.com/p/ganeti/issues/detail?id=1173
I reported this independently as #1179, and there is some more detail there.
I don't think this is anything to do with the name in the *cluster*
certificate.
If you move an instance from nodeX to nodeY, then nodeY has a listening SSL
socket, and nodeX makes an outbound connection to nodeY. However, from what
I can see, ganeti is passing nodeY's IP address (not hostname) to socat to
establish the connection.
socat 1.7.3 now enforces that the certificate name of the target host must
match the name of the host you are connecting to. From man socat:
NOTE: Up to version 1.7.2.4 the server certificate was only
checked for validity
against the system certificate store or cafile or capath,
but not for match with
the server’s name or its IP address. Since version 1.7.3.0
socat checks the peer
certificate for match with the <host> parameter or the value
of the openssl-com‐
monname option. Socat tries to match it against the
certificates subject common‐
Name, and the certifications extension subjectAltName DNS
names.
The node certificates do contain the correct commonname:
root@nuc2:~# openssl x509 -in /var/lib/ganeti/client.pem -noout -text |
grep CN
Issuer: CN=ganeti.example.com
Subject: CN=nuc2.ws.nsrc.org
The problem is that ganeti should be passing the hostname, not IP address,
to socat.
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
