search for: certtools

Hello, I'm using certtool to generate the server certificates for ESXi - http://libvirt.org/remote.html#Remote_TLS_CA. I just copy the server certificate and key as /etc/vmware/ssl/rui.crt and /etc/vmware/ssl/rui.key. And then use virsh to connect from a CentOS 6.4 VM running on it - "virsh -c esx://<esx IP>. I get the following error - error: internal error curl_easy_perform()

On Tue, Oct 29, 2013 at 06:48:46PM -0700, Shiva Bhanujan wrote: > Hello, > > I'm using certtool to generate the server certificates for ESXi - > http://libvirt.org/remote.html#Remote_TLS_CA. I just copy the server > certificate and key as /etc/vmware/ssl/rui.crt and /etc/vmware/ssl/rui.key. > And then use virsh to connect from a CentOS 6.4 VM running on it - "virsh

2013/10/30 Shiva Bhanujan <sxb075@gmail.com>: > Hi Daniel, > > thanks for the reply - The procedure I use is the same as I use for > XenServer, and the certificate exchange works just fine. The only thing I'm > a bit unclear on, is the location of the CA cert, which in the case of > XenServer, I simply put it in /etc/pki/CA. And when I start the libvirtd > daemon,

Hi Daniel, thanks for the reply - The procedure I use is the same as I use for XenServer, and the certificate exchange works just fine. The only thing I'm a bit unclear on, is the location of the CA cert, which in the case of XenServer, I simply put it in /etc/pki/CA. And when I start the libvirtd daemon, it successfully picks it up. If I put the Server key and cert in /etc/vmware/ssl for

Hi, I have couple of RHEV hosts (ovpxen,RHV2, RHV10 etc) and i'm trying to connect from one of the client machine (C1). All the RHEV host have libvirt modified by vdsm. It looks like the below ## beginning of configuration section by vdsm-4.10.2 listen_addr="0.0.0.0" unix_sock_group="kvm" unix_sock_rw_perms="0770" auth_unix_rw="sasl"

The public cert part is good, but the private one begins with "Begin private key", not "RSA key." On Sun, 14 Jun 2015 15:54:23 +0200, you wrote: >Am 13.06.2015 um 22:11 schrieb Steve Matzura: >> On Sat, 13 Jun 2015 21:57:06 +0200, you wrote: >> >>> On Sat, Jun 13, 2015 at 03:41:26PM -0400, Steve Matzura wrote: >>>>>>>> Trying

Hello, I am currently trying to install certificates for tls. By this time I have got some questions: 1) Is documentation in the web docs up-to-date regarding tls server, client, ca certificates? (actually I have some problems, but maybe this is due to smth has changed in certtools and was not updated in docs, perhaps some more fields are needed now). 2) there is a error in virt-pki-validate : when determining whether host name matches CN name you assume, that CN is standing in the end. So I get an error: The server certificate does not seem to match the host name hostname:...

Thanks for the response. My current chain is as follows: caroot -> child-ca1 -> server cert My cacert.pem file has both the caroot and the child-ca1 certs. I have recompiled libvirt on my machine with some extra debug statements and verified that both the caroot cert and the child-ca1 certs are being loaded. But when I try to connect the caroot and child-ca1 certs only appear under the

Currently we test for qemu-img, socat, ss, certtool, etc at run time, but we test for qemu-io at compile time (in ./configure). This commit removes this inconsistency. I would consider the opposite patch (which makes qemu-img etc tested at configure time). The main advantage of testing for these binaries at run time is that tests are not "silently" omitted. Instead tests with

I was wondering if anyone has managed to get a trusted certificated to work with Xen''s Encrypted VNC and Vencrypt? I can generate my own cert with Certtool and this works but as expected I get warnings from Vencrypt: "Certificate Issuer Unknown" "Certificate Not Trusted" "Hostname Mismatch" After some time working with my Cert provider I have a CA signed

On Tue, Apr 22, 2014 at 08:24:43AM -0600, Nathaniel Cook wrote: > Thanks for the response. > > My current chain is as follows: > > caroot -> child-ca1 -> server cert > > My cacert.pem file has both the caroot and the child-ca1 certs. I have > recompiled libvirt on my machine with some extra debug statements and > verified that both the caroot cert and the

On 9/17/19 5:35 PM, Richard W.M. Jones wrote: > This neutral refactoring adds -DTLS_MODE. We can in future change the > requested TLS mode, but not in this commit. > > It also checks that nbd_get_tls_negotiated returns true after > connecting, when the requested mode was set to LIBNBD_TLS_REQUIRE. > --- > interop/Makefile.am | 4 ++++ > interop/interop.c | 26

Quoting Gedalya <gedalya at gedalya.net>: > On 05/27/2015 09:55 AM, Rick Romero wrote: >> Quoting Gedalya <gedalya at gedalya.net>: >> >>> On 05/26/2015 10:37 AM, Ron Leach wrote: >>>> https://weakdh.org/sysadmin.html >>>> >>>> includes altering DH parameters length to 2048, and re-specifying the >>>> allowable

On 8/7/20 5:00 PM, Eric Blake wrote: > Take advantage of the fact that we can now detect the type of client > during --tls=on in order to provide safe dummy content for plaintext > clients without having to rewrite plugins to do so. > > Signed-off-by: Eric Blake <eblake@redhat.com> > --- I got a test working (although it still shows that we are bit awkward until nbdkit

v2: * Improved documentation. * Added a test (interop with qemu client).

As scheduled, libvirt 0.9.0 was tagged and pushed today, it's available from FTP at: ftp://libvirt.org/libvirt/ This is a large release w.r.t. the amount of features and changes, and well worth bumping the middle version number. We are also getting closer to a 1.0.0 release ! Features: - Support cputune cpu usage tuning (Osier Yang and Nikunj A. Dadhania) - Add public APIs for storage

Patch 3 still needs tests added, but it is at least working from my simple command line tests. Eric Blake (3): server: Implement nbdkit_is_tls for use during .open server: Expose final thread_model to filter's .get_ready tlsdummy: New filter docs/nbdkit-filter.pod | 21 +- docs/nbdkit-plugin.pod | 34 ++- docs/nbdkit-tls.pod

libnbd-0.1.4-1 is now available in Fedora 29/30 updates testing. Diffs since v2 - rebase to master, bump from libnbd 0.1.2 to 0.1.3+, add tests to TLS usage which flushed out the need to turn relative pathnames into absolute, doc tweaks Now that the testsuite covers TLS and libnbd has been fixed to provide the things I found lacking when developing v2, I'm leaning towards pushing this on