Description of problem: ========================================= libvirt 1.0.2: tests/test-suite.log ========================================= # TOTAL: 83 # PASS: 80 # SKIP: 2 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 FAIL: virnettlscontexttest ========================== TEST: virnettlscontexttest 1) TLS Context ... OK 2) TLS Context ... OK 3) TLS Context ... OK 4) TLS Context ... OK 5) TLS Context ... OK 6) TLS Context ... libvir: XML-RPC error : Our own certificate servercert.pem failed validation against cacert5.pem: The certificate is not trusted. FAILED 7) TLS Context ... libvir: XML-RPC error : The certificate cacert6.pem is missing basic constraints for a CA OK 8) TLS Context ... libvir: XML-RPC error : Certificate cacert7.pem usage does not permit certificate signing OK 9) TLS Context ... OK 10) TLS Context ... OK 11) TLS Context ... OK 12) TLS Context ... OK 13) TLS Context ... OK 14) TLS Context ... OK 15) TLS Context ... OK 16) TLS Context ... libvir: XML-RPC error : Certificate servercert8.pem usage does not permit digital signature OK 17) TLS Context ... libvir: XML-RPC error : Certificate servercert9.pem purpose does not allow use for with a TLS server OK 18) TLS Context ... libvir: XML-RPC error : Certificate servercert10.pem usage does not permit digital signature OK 19) TLS Context ... OK 20) TLS Context ... OK 21) TLS Context ... OK 22) TLS Context ... OK 23) TLS Context ... OK 24) TLS Context ... OK 25) TLS Context ... OK 26) TLS Context ... libvir: XML-RPC error : Certificate clientcert8.pem usage does not permit digital signature OK 27) TLS Context ... libvir: XML-RPC error : Certificate clientcert9.pem purpose does not allow use for with a TLS client OK 28) TLS Context ... libvir: XML-RPC error : Certificate clientcert10.pem usage does not permit digital signature OK 29) TLS Context ... libvir: XML-RPC error : The CA certificate cacert.pem has expired OK 30) TLS Context ... libvir: XML-RPC error : The server certificate servercert.pem has expired OK 31) TLS Context ... libvir: XML-RPC error : The client certificate clientcert.pem has expired OK 32) TLS Context ... libvir: XML-RPC error : The CA certificate cacert.pem is not yet active OK 33) TLS Context ... libvir: XML-RPC error : The server certificate servercert.pem is not yet active OK 34) TLS Context ... libvir: XML-RPC error : The client certificate clientcert.pem is not yet active OK 35) TLS Session ... OK 36) TLS Session ... libvir: XML-RPC error : authentication failed: Failed to verify peer's certificate OK 37) TLS Session ... OK 38) TLS Session ... OK 39) TLS Session ... libvir: XML-RPC error : authentication failed: Failed to verify peer's certificate OK 40) TLS Session ... libvir: XML-RPC error : authentication failed: Failed to verify peer's certificate OK 41) TLS Session ... OK 42) TLS Session ... OK 43) TLS Session ... libvir: XML-RPC error : authentication failed: Failed to verify peer's certificate OK 44) TLS Session ... OK 45) TLS Session ... OK 46) TLS Session ... libvir: XML-RPC error : authentication failed: Failed to verify peer's certificate OK 47) TLS Session ... OK 48) TLS Session ... OK SKIP: statstest =============== TEST: statstest SKIP: reconnect =============== TEST: reconnect Version-Release number of selected component (if applicable): libvirt from git How reproducible: 100% Steps to Reproduce: 1. Install Rawhide. 2. Do 'make check' in libvirt. 3. Additional info: https://www.redhat.com/archives/libvir-list/2013-February/thread.html#01673
Reassigning to gnutls, based on: https://www.redhat.com/archives/libvir-list/2013-February/msg01675.html "In that test case we're creating a CA cert which has the key-usage policy set to "digital signature" instead of "key signing". However we also set the flag "non-critical" so a failing key usage policy check should still result in a pass from cert validation. Sounds like gnutls3 isn't liking this."
Can you attach the CA cert you're creating?
Created attachment 704143 [details] The CA certificate (notice bogus key usage, but marked non-critical)
Created attachment 704144 [details] The server cert which should validate
Here is the test itself: http://libvirt.org/git/?p=libvirt.git;a=blob;f=tests/virnettlscontexttest.c;hb=HEAD
Created attachment 704145 [details] Fixed: The CA certificate (notice bogus key usage, but marked non-critical)
Created attachment 704146 [details] Fixed: The server cert which should validate
Created attachment 704147 [details] A test case to demo what libvirt does On my Fedora 18 system this results in: # gcc -Wall -o tlsvalid tlsvalid.c `pkg-config --cflags --libs gnutls` # ./tlsvalid cacert5.pem servercert.pem Certificate is ok I've not tested this demo program on F19, but I believe it should fail in the same way as the libvirt test case fails
The output of Dan's program on Fedora Rawhide (x86-64): $ ./tlsvalid cacert5.pem servercert.pem Failed validation The certificate is not trusted.
I think this is not a bug and compliant with RFC 3280. Citing it: (n) If a key usage extension is present, verify that the keyCertSign bit is set. ... If check (a), (k), (l), (n) or (o) fails, the procedure terminates, returning a failure indication and an appropriate reason. There is nowhere stated that when Key usage without keyCertSign bit can be ignored when it is marked non-critical.
Hmm, so this could be due to a misunderstanding of the effect of 'critical' vs 'non-critical'. On closer inspection of the RFC, it appears that this flag is only to have effect when a TLS impl does not support the extension in question. If the extension is marked 'critical' then lack of support should be a fatal error, if it is marked 'non-critical' then lack of support means the extension can be ignored. This does, however, raise the question of why gnutls 2.x successfully validates this certificate - it seems like this could be a bug in that version of gnutls ?
Yes, sure, this is a bug in older gnutls versions but one that is pretty harmless and so it does not warrant fixing it there. Also changing this on already deployed systems is not good exactly because of the reasons like this bug.
Fixed in upstream libvirt commit 0204d6d7a0519377b2e6bc296b00328cd748f55d Author: Daniel P. Berrange <berrange> Date: Mon Mar 4 17:27:38 2013 +0000 Fix TLS tests with gnutls 3 When given a CA cert with basic constraints to set non-critical, and key usage of 'key signing', this should be rejected. Version of GNUTLS < 3 do not rejecte it though, so we never noticed the test case was broken Signed-off-by: Daniel P. Berrange <berrange>
This was in libvirt 1.0.3