On Wed, Nov 17, 2010 at 02:53:15PM +0100, Matthias Bolte wrote:
2010/11/17 Justin Clift <jclift(a)redhat.com>:
> Also added an additional menu placement for the windows page, in
> order to attract further potential testers.
> ---
> + <li>
> + The working connection types at the moment are very limited. Only
> + <b>qemu+tcp://</b> is known to work for sure. Anything using
SSH,
> + such as <b>qemu+ssh://</b>, definitely doesn't work.
Connecting
> + to ESX servers doesn't yet work either, due to a bug involving
> + GnuTLS, which should be fixed in the next release.
> + </li>
Don't blame GnuTLS here. As stated on IRC my initial assumption was
wrong. The problem is probably not in GnuTLS, as gnutls-cli works
fine. The problem is in the way libcurl and GnuTLS interact. Therefore
libvirt's GnuTLS usage is not affected, only libcurl's.
I know how to fix it, but I don't understand in detail yet why it works.
Are you referring to this message ?
"A TLS packet with unexpected length was received"
The place you normally see this is from 'gnutls_handshake()', and it is
an indication that the handshake has been aborted by either the client
or server. Typical problems include bad certificates, bad choice of
encryption ciphers, bad TLS protocol, etc. It is pretty hard to
debug, likely want to turn on the verbose GnuTLS debugging options
in the code, and also verify how the ESX server is configured and
all your certificates
In particular, by default GnuTLS will reject certificates issued by
openssl which default to x509 v1, and thus lack the 'Basic Constraints'
extension from x509 v3.
Daniel
--
|: Red Hat, Engineering, London -o-
http://people.redhat.com/berrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org -o-
http://deltacloud.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|