Bug 723447

It's the upstream commit 79591d4fbf666a5b1a5b93c9f30ddc81e77d593a

   Add sanity checking of basic constraints, key purpose & key usage
    
    Gnutls requires that certificates have basic constraints present
    to be used as a CA certificate. OpenSSL doesn't add this data
    by default, so add a sanity check to catch this situation. Also
    validate that the key usage and key purpose constraints contain
    correct data
    
    * src/rpc/virnettlscontext.c: Add sanity checking of certificate
      constraints

in that case gnutls_x509_crt_get_basic_constraints() returns 0 indicating
it doesn't think that this is a CA certificate.

RETURN VALUE
       If the certificate is a CA a positive value will be returned,  or  zero
       if  the certificate does not have CA flag set.  A negative value may be
       returned in case of errors.  If the certificate does  not  contain  the
       basicConstraints  extension  GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE will
       be returned.

then gnutls_x509_crt_get_key_usage() just fails on that certificate ad that
leads to the abort.
I note that we are passing NULL values for a bunch of arguments of gnutls
maybe this is working fine in recent versions but leads to troubles on the
RHEL-6 one ... we should check this

Daniel

Please attach both your CA certificate, and the VDSM server certificate to this bug

> query certificate /etc/pki/vdsm/certs/vdsmcert.pem basic constraints The
requested data were not available.

This error message is actually wrong. It is actually missing 'key usage' data from the certificate. In the past libvirt did not enforce presence of this data, but now it does. While the CA cert looks OK, I believe the server certificate (vdsmcert.pem) was not created following the libvirt documentation.

When creating a server certificate, you need to create a .info file for certtool containing the following information:

#cat > server.info <<EOF
organization = Name of your organization
cn = fully.qualified.server.hostname
tls_www_server
encryption_key
signing_key
EOF

The 'tls_www_server', 'encryption_key' and 'signing_key' bits ensure you get the key usage & key purpose extension fields are filled in for the certificate.

For a correctly generated server cert,  'certtool -i --infile /path/to/cert' should show

        Extensions:
                Basic Constraints (critical):
                        Certificate Authority (CA): FALSE
                Key Purpose (not critical):
                        TLS WWW Server.
                Key Usage (critical):
                        Digital signature.
                        Key encipherment.

While a client certificate should show

	Extensions:
		Basic Constraints (critical):
			Certificate Authority (CA): FALSE
		Key Purpose (not critical):
			TLS WWW Client.
		Key Usage (critical):
			Digital signature.
			Key encipherment.

And a CA cert should show

        Extensions:
                Basic Constraints (critical):
                        Certificate Authority (CA): TRUE
                Key Usage (critical):
                        Certificate signing.

Opps, missed out the docs link for how to generate certs:

http://libvirt.org/remote.html#Remote_TLS_server_certificates

Created attachment 513977 [details]
vdsmcert.pem, cacert.pem

attached both cacert and vdsmcert.

While the VDSM certs are missing the key usage/purpose data, re-checking the relevant RFCs shows we should have treated that as non-fatal by default. We should only treat it as a fatal problem if the key usage + purpose *is* in the certificate and marked as 'critical':
	
http://www.redhat.com/archives/libvir-list/2011-July/msg01333.html


In addition to that, to get RHEV/VDSM to follow best practice recommendations from the libvirt.org/remote.html when generating certificates, there are a couple of changes that should be made to RHEV-M's code:

In the file:

   rhevm/backend/manager/conf/ca/cert.template

There should be two extra fields set under the '[ v3_ca ]' heading, just after the basicConstraints data:

For client certificates:

  keyUsage=critical,digitalSignature,keyEncipherment
  extendedKeyUsage=critical,clientAuth

For server certificates:

  keyUsage=critical,digitalSignature,keyEncipherment
  extendedKeyUsage=critical,serverAuth


It seems like VDSM might in fact need a dual purpose certificate, which can be done with

  keyUsage=critical,digitalSignature,keyEncipherment
  extendedKeyUsage=critical,serverAuth,clientAuth

To avoid future regressions in this area, I have created a comprehensive unit test case for libvirt's TLS cert handling

http://www.redhat.com/archives/libvir-list/2011-July/msg01490.html

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/RHBA-2011-1513.html