RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 825108 - unexpected result from virt-pki-validate
Summary: unexpected result from virt-pki-validate
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt
Version: 6.3
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: rc
: ---
Assignee: Martin Kletzander
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-05-25 07:00 UTC by dyuan
Modified: 2013-02-21 07:15 UTC (History)
9 users (show)

Fixed In Version: libvirt-0.9.13-3.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-02-21 07:15:36 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2013:0276 0 normal SHIPPED_LIVE Moderate: libvirt security, bug fix, and enhancement update 2013-02-20 21:18:26 UTC

Description dyuan 2012-05-25 07:00:16 UTC 
Description of problem:
virt-pki-validate always said "as root do: chmod 644 /etc/pki/libvirt/private/clientkey.pem" for client and "as root do: chmod 600 /etc/pki/libvirt/private/serverkey.pem" for server even after I conducted the chmod as it ask for.

Version-Release number of selected component (if applicable):
libvirt-client-0.9.10-20.el6

How reproducible:
Always

Steps to Reproduce:

========step for virt-pki-validate=====

step 1 : run #virt-pki-validate

==========

step 2: run #mkdir -m 755 /etc/pki/libvirt ; chown root:root /etc/pki/libvirt

                #virt-pki-validate

==========

step 3: run #mkdir -m 755 /etc/pki/libvirt/private ; chown root:root /etc/pki/libvirt/private

                #virt-pki-validate

==========

step 4:

#  certtool --generate-privkey > cakey.pe

# cat ca.info

cn = 10.66.5.5
ca
cert_signing_key

# certtool --generate-self-signed --load-privkey cakey.pem --template ca.info --outfile cacert.pem
# cp cacert.pem /etc/pki/CA/
# scp cacert.pem 10.66.5.5:/etc/pki/CA/
# scp cacert.pem 10.66.5.48:/etc/pki/CA/          

then run #virt-pki-validate

# scp cakey.pem 10.66.5.48:/etc/pki/CA/private

# scp cakey.pem 10.66.5.5:/etc/pki/CA/private

==========

step 5: As Client:

# certtool --generate-privkey > clientkey.pem

# cat client.info  // Note that 10.66.5.48 is the client ip

country = GB
state = London
locality = London
organization = Red Hat
cn = 10.66.5.48
tls_www_client
encryption_key
signing_key

 # certtool --generate-certificate  --load-privkey clientkey.pem --load-ca-certificate /etc/pki/CA/cacert.pem \
--load-ca-privkey /etc/pki/CA/private/cakey.pem --template client.info --outfile clientcert.pem

# mkdir -p /etc/pki/libvirt/private

# cp clientkey.pem /etc/pki/libvirt/private
# cp clientcert.pem /etc/pki/libvirt/
run # virt-pki-validate

step 5: As Server:

# certtool --generate-privkey > serverkey.pem

# cat server.info  

organization = Red Hat
cn = 10.66.5.5
tls_www_server
encryption_key
signing_key

# certtool --generate-certificate --load-privkey serverkey.pem --load-ca-certificate /etc/pki/CA/cacert.pem \
--load-ca-privkey /etc/pki/CA/private/cakey.pem --template server.info --outfile servercert.pem

# mkdir -p /etc/pki/libvirt/private

# cp serverkey.pem /etc/pki/libvirt/private

# cp servercert.pem /etc/pki/libvirt

run #virt-pki-validate

==========

step 6: On client

# chmod 644 /etc/pki/libvirt/private/clientkey.pem
# virt-pki-validate


step 6: On server

# chmod 600 /etc/pki/libvirt/private/serverkey.pem

# vim /etc/sysconfig/libvirtd

# service libvirtd restart 

or

# initctl restart libvirtd

# virt-pki-validate

 
Actual results:
On client

Found /usr/bin/certtool
Found CA certificate /etc/pki/CA/cacert.pem for 10.66.5.5
The CA certificate and the client certificate do not match
CA organization: 10.66.5.5
Client organization: Red Hat
Found client certificate /etc/pki/libvirt/clientcert.pem for 1
Found client private key /etc/pki/libvirt/private/clientkey.pem
The client private key need to be read by client tools
as root do: chmod 644 /etc/pki/libvirt/private/clientkey.pem
Did not find /etc/pki/libvirt/servercert.pem server certificate
The machine cannot act as a server
see http://libvirt.org/remote.html#Remote_TLS_server_certificates
on how to regenerate it


On server
Found /usr/bin/certtool
Found CA certificate /etc/pki/CA/cacert.pem for 10.66.5.5
Did not find /etc/pki/libvirt/clientcert.pem client certificate
The machine cannot act as a client
see http://libvirt.org/remote.html#Remote_TLS_client_certificates
on how to regenerate it
The CA certificate and the server certificate do not match
CA organization: 10.66.5.5
Server organization: Red Hat
The server certificate does not seem to match the host name
hostname: "rhel62-release.nay.redhat.com"
Server certificate CN: "10.66.5.5"
Found server certificate /etc/pki/libvirt/servercert.pem for 10.66.5.5
Found server private key /etc/pki/libvirt/private/serverkey.pem
The server private key need to be read only by root
as root do: chmod 600 /etc/pki/libvirt/private/serverkey.pem
Make sure /etc/sysconfig/iptables is setup to allow
incoming TCP/IP connections on port 16514 and
restart the iptables service

Expected results:
After I conducted the chmod for the clientkey.pem and serverkey.pem, it should not exist in the output of virt-pki-validate any more.

Additional info:
Comment 1 Martin Kletzander 2012-05-25 13:14:57 UTC 
I cannot reproduce this with 0.9.11, could you please try it with latest libvirt? It's enough to show the output of `ls -al /etc/pki/libvirt/private/serverkey.pem` and `virt-pki-validate`. Thanks
Comment 2 dyuan 2012-05-28 15:09:49 UTC 
I tested it with libvirt-client-0.9.10-21.el6. 
And I'll re-check it with 0.9.11, if it's not existing in 0.9.11, then I'll verify this bug with the rebase version for rhel6.4.

On client:
# virt-pki-validate 
Found /usr/bin/certtool
Found CA certificate /etc/pki/CA/cacert.pem for 10.66.5.5
The CA certificate and the client certificate do not match
CA organization: 10.66.5.5
Client organization: Red Hat
Found client certificate /etc/pki/libvirt/clientcert.pem for 1
Found client private key /etc/pki/libvirt/private/clientkey.pem
The client private key need to be read by client tools

as root do: chmod 644 /etc/pki/libvirt/private/clientkey.pem

Did not find /etc/pki/libvirt/servercert.pem server certificate
The machine cannot act as a server
see http://libvirt.org/remote.html#Remote_TLS_server_certificates
on how to regenerate it

# ls -la /etc/pki/libvirt/private/clientkey.pem 
-rw-r--r--. 1 root root 1675 May 23 16:11 /etc/pki/libvirt/private/clientkey.pem

On server:
# virt-pki-validate 
Found /usr/bin/certtool
Found CA certificate /etc/pki/CA/cacert.pem for 10.66.5.5
Did not find /etc/pki/libvirt/clientcert.pem client certificate
The machine cannot act as a client
see http://libvirt.org/remote.html#Remote_TLS_client_certificates
on how to regenerate it
The CA certificate and the server certificate do not match
CA organization: 10.66.5.5
Server organization: Red Hat
The server certificate does not seem to match the host name
hostname: "rhel62-release.nay.redhat.com"
Server certificate CN: "10.66.5.5"
Found server certificate /etc/pki/libvirt/servercert.pem for 10.66.5.5
Found server private key /etc/pki/libvirt/private/serverkey.pem
The server private key need to be read only by root

as root do: chmod 600 /etc/pki/libvirt/private/serverkey.pem

Make sure /etc/sysconfig/iptables is setup to allow
incoming TCP/IP connections on port 16514 and
restart the iptables service

# ls -la /etc/pki/libvirt/private/serverkey.pem 
-rw-------. 1 root root 1675 May 23 16:27 /etc/pki/libvirt/private/serverkey.pem
Comment 3 Martin Kletzander 2012-05-29 07:27:37 UTC 
We tried to reproduce the bug with 0.9.6 and failed, so this is most probably not related to the version. I'll have a look at it.
Comment 4 Martin Kletzander 2012-06-07 06:49:28 UTC 
This was caused by SELinux context applied on the file, moving to POST:

commit d4fb6694a4b7d5c613136e3bfc1bbf8d6b98ec74
Author: Martin Kletzander <mkletzan>
Date:   Thu May 31 11:00:06 2012 +0200

    tools: make virt-pki-validate work with acls and xattrs
Comment 6 yanbing du 2012-07-25 08:28:30 UTC 
Test with libvirt-0.9.13-3.el6.x86_64
After chmod for serverkey.pem,  the output of virt-pki-validate changed, and no info like: "as root do: chmod 600 ". So the bug can be verified.

On server:
# virt-pki-validate
Found /usr/bin/certtool
Found CA certificate /etc/pki/CA/cacert.pem for 10.66.85.74
Did not find /etc/pki/libvirt/clientcert.pem client certificate
The machine cannot act as a client
see http://libvirt.org/remote.html#Remote_TLS_client_certificates
on how to regenerate it
The CA certificate and the server certificate do not match
CA organization: 10.66.85.74
Server organization: Red Hat
The server certificate does not seem to match the host name
hostname: "intel-e31225-8-3.englab.nay.redhat.com"
Server certificate CN: "10.66.85.74"
Found server certificate /etc/pki/libvirt/servercert.pem for 10.66.85.74
Found server private key /etc/pki/libvirt/private/serverkey.pem
The server private key need to be read only by root
as root do: chmod 600 /etc/pki/libvirt/private/serverkey.pem

# chmod 600 /etc/pki/libvirt/private/serverkey.pem
# virt-pki-validate
Found /usr/bin/certtool
Found CA certificate /etc/pki/CA/cacert.pem for 10.66.85.74
Did not find /etc/pki/libvirt/clientcert.pem client certificate
The machine cannot act as a client
see http://libvirt.org/remote.html#Remote_TLS_client_certificates
on how to regenerate it
The CA certificate and the server certificate do not match
CA organization: 10.66.85.74
Server organization: Red Hat
The server certificate does not seem to match the host name
hostname: "intel-e31225-8-3.englab.nay.redhat.com"
Server certificate CN: "10.66.85.74"
Found server certificate /etc/pki/libvirt/servercert.pem for 10.66.85.74
Found server private key /etc/pki/libvirt/private/serverkey.pem

On client:
# virt-pki-validate
Found /usr/bin/certtool
Found CA certificate /etc/pki/CA/cacert.pem for 10.66.85.74
The CA certificate and the client certificate do not match
CA organization: 10.66.85.74
Client organization: Red Hat
Found client certificate /etc/pki/libvirt/clientcert.pem for 1
Found client private key /etc/pki/libvirt/private/clientkey.pem
Did not find /etc/pki/libvirt/servercert.pem server certificate
The machine cannot act as a server
see http://libvirt.org/remote.html#Remote_TLS_server_certificates
on how to regenerate it
Comment 7 errata-xmlrpc 2013-02-21 07:15:36 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2013-0276.html
Note You need to log in before you can comment on or make changes to this bug.